ServiceNow offers a handy little feature on forms that use choice lists. The values populated in one field can determine the values in another. This is setup quite easily using field dependencies. Below is a simple example to illustrate. The values that will be populated in the ‘Model’ field are dependent on what is selected in ‘Make’.

CL0

This is really easy to setup in forms (see below), but is much more difficult in catalog items. The remainder of this article will provide a quick overview of achieving the same functionality in a catalog item.

Setting Up Field Dependencies (Forms)
The first thing you need to do is setup the field dependencies. To do so, right click the dependent field, in this case ‘Model’ and select the ‘Advanced view’. This will show the ‘Dependent Field’ tab. Check the ‘Use dependent field’ box and select the dependent field to the parent field, in this case ‘Make’.

CL3
Back on the form, all you need to do is set a value in the parent field, in this case ‘Make’. Once you have done this, right-click the dependent field, in this case ‘Model’ and select ‘Personalize Choices’.

CL00
This will take you to the form below. Notice that the value of the Make field is populated in the top left hand corner. At this point you can add/select the values you need to display in the ‘Model’ field as you would for any choice list. In this example, it is tying the values to only be visible if the parent ‘Make’ is set to ‘Mazda’.

CL2

That’s it, you’re done!!!
Just for reference, these values are stored in the System Definition > Choice Lists table (sys_choice).

CL4

Setting Up Field Dependencies (The Catalog)
Now, onto catalog items. Without going too much into how the catalog works, a catalog item or record producer refers to fields to be populated as variables. Continuing on from the example above, the ‘Make’ variable (parent) can simply be a ‘Select Box’ of the possible vehicles.

CL5

Similarly, you can populate the ‘Model’ field (dependent) to also be a ‘Select Box’ of the possible models. It really doesn’t matter what table you set this to, as long as it is a ‘Select Box’, but it’s better to choose something suitable.

CL6

Now for the fun part. To mimic the same behaviour in a catalog item you need to use ‘Service Catalog > Catalog Policy > Catalog Client Scripts’. The following code is a simple example that performs the following:

  • If the ‘Make’ changes to empty, then hide the ‘Model’ field
  • If the ‘Make’ changes to a value, perform a lookup on the ‘Choice List’ (sys_choice) table, and populate the ‘Model’ field with the possible choices.

Note: There is also a Catalog Client Script that sets the ‘Model’ field to hidden onLoad (as UI policies were not doing the job).

CL7

And that’s it, you can now have the same behaviour on a catalog item.

CL8

3 comments

I also found this very helpful, and rather surprising that ServiceNow doesn’t allow you to use the same dependent field option on the Portal that it does in the backend.

One note, I had to use a callback function instead the direct possibleChoice.query(); function you’ve used there, this may be due to a later version of ServiceNow forcing the use of callbacks from the client script.
The code that worked for me was:
possibleChoices.query(responseChoices);

function responseChoices(response){
while(response.next()){
g_form.addOption(‘u_advice_form’, response.value, response.label, response.sequence);
}

Cheers
Kieran

Robert Nightingale

Thanks for that, very helpful.

I added this to the query though.
pissibleChoices.addQuery(‘inactive’,false);

Cheers

Daniel Spavin

Hi Robert,

That’s a great addition – that will only show choices that are active.

Cheers
Daniel

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.