The Now Platform® Washington DC release is live. Watch now!

Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Dawn Jurek
ServiceNow Employee
ServiceNow Employee

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:

Incident form showing State choices final.jpg

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:

Choices for State field on Incident table final.jpg

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:

Change default value to 2 final.jpg

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!

Problem form showing default State as Known Error final.jpg

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:

Dictionary entry for State field-Task table final.jpg

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:

Dictionary Overrides for State field on the Task table final.jpg

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:

Define dictionary override for Incident Table final.jpg

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:

Incident-new record with State value of 2 final.jpg

Problem-new record with State value of 1 final.jpg

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."

9 Comments