ServiceNow provides you with the flexibility to customize forms so that they can mirror your business processes. But sometimes tinkering with default values can be tricky. In this installment of our best practices series, we look at how changing the default State field on one form can affect other forms as well. But not to worry: we also show you how to use the magic of dictionary overrides to avoid this pitfall.
Consider this Oops scenario:
In the base system, the default value for the State field on the Incident form is New, but you want the default value to be In Progress instead:
So you right-click the State label to show the choice list for this field, and filter it for the Incident table. You note that the Value corresponding to In Progress is 2:
Then you go back and right-click the State field on the Incident form again to configure the dictionary for this field, changing its Default value to 2:
It works! The default State value for new incidents is now In Progress. But there are also some unintended consequences. For example, the Problem form now displays a default State of Known Error. That's not right!
And some other forms are affected as well.
What went wrong?
If you had looked carefully at the dictionary entry for the State field when you changed the default value, you would have noticed that the change you made affected the Task table—not just the Incident table:
That's because the Incident table is a child class whose parent is the Task table. The Incident table inherited the State field from the Task table, and any changes made to this dictionary entry affect the Task table and all child tables extending from it. So, changing the default value of the State field on the Task table also changed the default State value for a bunch of other tables, including the Problem table.
The proper way to change the default State value for the Incident table without affecting the Task table or its extended tables is to use a dictionary override. First, we change that default State value back to 1, which is what it should be for most forms.
What are dictionary overrides and how do I create them?
Dictionary overrides allow system administrators to define certain field settings on an extended table differently from those on the parent table without affecting the parent table or its extended tables. Dictionary overrides are defined in the dictionary entry record for the field on the parent table. For example, here's the dictionary entry for the State field on the Task table, scrolled down to display the Dictionary Overrides related list:
Two dictionary overrides already exist for the State field on the Task table—one applies to the Change Request table and the other to the Standard Change Proposal table.
To define a new dictionary override to set the default State value on the Incident table to 2, click New and fill in the form, like this:
Here you can see which other settings can be overridden for the State field. As check boxes are selected, additional fields are displayed to specify the details for each override.
Now, with this new dictionary override, the incident form displays a default State value of 2, and the Problem form displays a default State value of 1, exactly as they should:
How dictionary overrides affect extended tables
Dictionary overrides are inherited by extended tables, so it may be necessary to define additional overrides to change the value of fields on extended tables. For example, if you define the default value of cmdb_ci.install_status to be 3, and create an override for the same field on cmdb_ci_hardware to be 5, all tables extended from the Hardware table will also default to 5. So if you want the default cmdb_ci_computer.install_status to be 3, you will need another override.
Best Practice: Align state values across applications
A related best practice is to align the State field values. These aren't always aligned in the base system, but generally, a State of 3 means closed, regardless of whether the record is an incident, a problem, or a change. If you alter the states, try to keep them aligned across all the applications. This may be easier said than done, but it is useful. For example, you can then make a report on the Task table, and see all closed tasks with one filter, rather than lots of OR conditions.
Want to learn more about tables, records and fields? Check out this video:
For more information, see:
--
Behind the scenes here at ServiceNow, the Knowledge Management and Multimedia teams work closely with subject matter experts to disseminate critical information to our customers. We've found that certain topics come up frequently, in the form of best practices that can help you keep your ServiceNow instances running smoothly. This series targets those topics so that you and your organization can benefit from our collective expertise. If you have a best practices topic you'd like us to cover in this series, please let us know in the comments below.
To access all of the blog posts in this series, search for "nowsupport best practices series."
10 Comments
