Dependent fields

Thinking about dependent fields

      In this article we'll discuss about dependent fields.

Database diagram

      The diagram above represents a database infrastructure that we need to maintain in our ServiceNow application.

      Suppose we've finished the gathering requirements phase and, as a Technical Consultant, the User Stories that we need to develop are:

      1) In the front-end, provide a Record Producer so the user can create a new record containing: a) Manufacturer, b) Vehicle and c) Vehicle model*.

      2) In the back-end, a user with a special role is able to edit that fields if necessary.

      Step by step process

      Since we're talking about choices that will be available to the end user, all tables involved should be previously populated with the correct information before the delivery of this Record Producer. For example: If the source of the information is an external database, we need to create an integration to make sure that the tables are always populated with accurate information.

      In this article we'll suppose that you already have it solved and the database infrastructure is up to date.

      1) The Front-end
      As common user interfaces to input data we have Record Producers (Service Portal), Workspaces and Mobile. The interface we need to provide in this scenario is a Record Producer.

      We should arrange the Choice Lists according to our database infrastructure. So the first choice will be Manufacturer, then Vehicle and the last will be the Model.

      A good practice is to include the option None. With this, our Choice Lists can be set as mandatory fields and we reduce the chance of receiving innacurate data.

Record Producer

      Did you see that we've created a field called Active in every table? If the process admin set a record as inactive in the back-end, we want to hide that option within the Record Producer Choice List. To to that, we need to use some code within our Record Producer variables like this:

      This will retrieve only active records from the database.

      When a Manufacturer is selected, we need to populate the Vehicle Choice List with the vehicles related to that selected Manufacturer. You'll need to configure your Vehicle Choice List with some code too:

javascript:'active=true^manufacturer=' + current.variables.manufacturer
      Commenting the code: The first 'manufacturer' is the Vehicle's table column name which is a reference to the Manufacturer's table. The 'current.variables.manufacturer' will read the option the user selected in the RP Choice List named 'manufacturer'.

      You got the idea. Use the same logic for the Model Choice List.

      2) The Back-end

      In the back-end the three fields, by default, retrieve all records from the tables.

      Remember to keep it simple

      Since the Vehicle should show available vehicles depending on the selected manufacturer, we can configure in the Cars table this dependency:

Vehicle field

      The Model should show available models depending on the selected Vehicle, then we can configure in the Cars table this dependency:

Vehicle field

      Thanks for reading!

Do not consider the model efficiency. It was created just for educational purposes.
There's a table called sys_choice but it isn't in the scope of this article.