Three-tier dependencies in ServiceNow: A common pitfall

Disclaimer: This is an option, but our team at Pathways always recommends refraining from using three-tier dependencies. Sometimes our customers fall into the pitfalls of three-tier dependencies, a common “solution.” This article states why we think you should stay away from this idea.

When configuring a three-tier hierarchy, there are several caveats that need to be taken into consideration. These stem from the way ServiceNow allows dependent fields to be configured. ServiceNow only allows you to specify one “depended on” field when defining a choice field. Essentially the field hierarchy ends up looking like this.

The “Lower tier” field has no direct knowledge of the “Top tier” field, only indirectly by what value is selected for the “Middle tier” field. This ends up being fine for hierarchies that never share a common “Middle tier” value. But when there happen to be common “Middle tier” values we start to run into issues. The first issue is that “Low tier” values that depend on common “Middle tier” values may or may not be the same for all common “Middle tier” values. Imagine the following field dependency with a three-tiered hierarchy:

You can see here that Cat and Dog for the Top tier field share a common “Middle tier” value in “Eye color”. This typically wouldn’t be an issue, but as you see from the matrix, when “Cat” is selected for “Top tier” and “Eye color” is selected from “Middle tier”, “Low tier” should contain a value called Blue. However, if “Dog” is selected for “Top tier” and “Eye color” is selected for “Middle tier” value Blue for “Low tier” should not be available. This is where the break down is. If we look back at the first diagram you can see that the Low tier field has nothing to indicate what was selected by “Top tier”, only that “Eye color” is selected for the “Middle tier” field. So, to get around this, there are two options:

1. Ensure all “Middle tier” values are distinct. This would mean that instead of a general “Eye color”, we would need to specify distinct “Eye color”s for each value in our “Top tier”. This would also cause all our “Low tier” values to be distinct as well. Our values would then need to look something like

The downside to this approach is that when you attempt to report on a table with a hierarchy like this where you want all records where  “Low tier” = “Green”, you will actually need to specify all Green choices (Green.1, Green.2, etc.). This is likewise for tier 2. As you can imagine, this can get out of hand with larger dependency matrices.

2. The other option would be to forgo ServiceNow’s native field dependency solution and to script the entire set of dependencies. This solution is possible but inadvisable as it would be a significant amount of development work (based on the number of values in each tier) and could become an issue maintaining. As new values are added, it would be a programmatic change (possibly a large change for adding a single value) to update.