0% found this document useful (0 votes)
223 views6 pages

Dictionary Overrides-What They Are and How To Use Them: Best Practices Series

Dictionary overrides allow administrators to customize field settings like default values for specific tables without affecting the parent table or other extended tables. They work by defining overrides in the dictionary entry of the field on the parent table. For example, an override was created to set the default state of new incidents to "In Progress" by overriding the state field dictionary on the task table for just the incident table. This allowed the different default to be set for incidents without changing defaults on other related forms.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
223 views6 pages

Dictionary Overrides-What They Are and How To Use Them: Best Practices Series

Dictionary overrides allow administrators to customize field settings like default values for specific tables without affecting the parent table or other extended tables. They work by defining overrides in the dictionary entry of the field on the parent table. For example, an override was created to set the default state of new incidents to "In Progress" by overriding the state field dictionary on the task table for just the incident table. This allowed the different default to be set for incidents without changing defaults on other related forms.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

Dictionary overrides—what they are and how to

use them

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.

You might also like