Cannot create a dynamic choice list in a form for a dependent reference field.

[mikebcn]

I have 2 reference fields in a form.
The allowed value in the second field is restricted by the current value of the first field.
The possible values for the second field are determined by a javascript function (in a business rule) called by the Reference qualifier for the second field.
On changing the value in the first field the choices available for the second field change.
This is the behavior that is required.
When I open the Reference Lookup for the second field the values displayed are correct and are related to the value in the first field.
If I change the value in the first field the values displayed in the Reference Lookup for the second field change accordingly.

I would like to do the exact same thing but with the second field being a choice list.
I have tried to do this by defining the second field as a choice list by modifying its dictionary entry.
But the available options that appear are not being restricted by the value in the first field.
Also, changing the value in the first field does not cause a change in the option list of the second field.

I also tried implementing the same behaviour using a client script triggered by the onchange event in the first field. I can remove options from the choice list but I can not find a way for the glide_form addOption() function to work.
I got no javascript errors in the browser, just no options added to the choice list.

Is it possible to create a dependent field which is a choice list with the behavior that I want? ie. a dynamic choice list whose options are determined by the value chosen for another field.
thanks in advance
mike

[Mark Stanger]

Yes, this assumes that the second field is a standard choice field - no reference involved. If the reference field method isn't working then you'll want to contact ServiceNow support as it's probably a bug or enhancement.

[mikebcn]

As I said in the original question, I have 2 reference fields with the second one being dependent on the first one. As a "normal" reference field the possible values the second field can have are dependent on the value in the first field. Thus the function defined for, and called by, the "Reference Qual:" field is working correctly.
On changing the second field to a choice list (by personalizing the dictionary) is when it stops working correctly. As mark suggested, it might well be a bug in Service Now.
mike

[DaleHurtt]

Granted, it is not the solution you are looking for, but it may meet your requirements.

1. I created a table that contained the two fields and loaded in the test data.
2. I created the two fields on the main form that are to reference the fields in the table from step 1. I created these fields as Choice, not Reference.
3. I added a Reference field to the table created in step 1.
4. I loaded the data from step 1 into the Choice List dictionary, setting the fields as appropriate. The key is the "Dependent value" column so that the second field's value is constrained by the first.
5. I created a Business Rule that fills in the Reference field created in step 3 based on matching the values in the two Choice fields to the record in the table from step 1.

I hope that makes sense. In a nutshell, you have the data stored twice, once in a table and once in the dictionary as Choice Lists. To set the (hidden) reference field, use a Business Rule.

It has its problems, to be sure. You have the data duplicated, and you have to keep them in sync. Presumably the goal is to keep the data in the fields in sync with the data in the reference form?

One of the things that this little exercise has convinced me of is that methods used to create a solution in one product (that shall remain nameless) does not exactly work for another. Dependent fields (fields where the value of the second is dependent upon the value in the first, the value of the third is dependent upon the value of the second, etc.) are relatively easy to implement using menus with queries behind them. The ServiceNow Way appears to be to use Choice Lists.

One of the things I found out while exploring is that Choice fields are tied to their Dictionary entries. It is a pseudo-reference field. Assume you have two fields, Category and Sub-Category, and you make them Choice fields. When you define the Sub-Category values you make them dependent upon a Category value. If you were to create a record setting values in these fields, and then subsequently change a Sub-Category choice in the dictionary, all records that referenced that initial value will automatically display the new changed value. That shows you that a Choice field is not the same thing as a String field that has a selection list attached.

I hope this helps. If not, well at least I learned something new! :^)