What Is A Dictionary Override In ServiceNow?

What Is A Dictionary Entry?

Before diving into dictionary overrides, you first need to understand what a dictionary entry is.

Every single field, is tied back to a dictionary entry. It’s really as simple as that.

If you’re on the incident form, and you create a new custom field – you have just created a new dictionary entry (this automatically happens – because you’re creating a new field).

So when you’re on a form and you want to add a new field to it, you can actually do it one of 2 ways.

You can customize the form and add a field that way. Which in the background, is creating a dictionary entry for you.

Or you can just go to the dictionary entries table [sys_dictionary] and you can create a new record here.

Either way, every single field on every single form is a dictionary entry.

Now that we’ve covered dictionary entries a bit, let’s discuss what a dictionary override would be.

In summary: you can create dictionary overrides, for fields on child tables – when you don’t want to modify the properties of the parent field. You are “overriding” the parent dictionary entry, and you are specifying that you want a child field to behave differently. This may be a different field name, making it mandatory, adding a reference qualifier to it, etc.

Let’s talk about a couple examples.

What To Know When Creating A New Field/Dictionary Entry

ServiceNow Admins have to create fields to put on forms so end users can populate it with data.

But when you’re adding new fields, or modifying existing ones, what sort of fields can you create?

There’s a huge difference between a description field, a number field and a choice field. This is all defined, when a field is created, and should never be modified afterwards.

When creating a new field on a form in ServiceNow, there are several decisions that a ServiceNow administrator needs to make:

1. Field Name: The field name should be clear, concise, and meaningful. It should also follow ServiceNow’s naming conventions.
2. Data Type: The administrator needs to decide on the data type of the field, such as string, integer, date, or reference to another table. This will determine the type of data that can be entered into the field and how it is stored in the database.
3. Field Label: The administrator needs to choose a label that will be displayed on the form in the user interface. It should be easy to understand and meaningful for users.
4. Field Size: The administrator needs to decide on the size of the field, such as the maximum length of a string field or the number of decimal places for a numeric field.
5. Field Place: The administrator needs to decide on the location of the field on the form. This will affect the user’s experience when filling in the form.
6. Mandatory: The administrator needs to decide if this field is mandatory or optional. If it’s mandatory, users will have to fill in the field before they can save the form.
7. Read-only: The administrator needs to decide if this field will be editable by users or not. If it’s not editable, users will not be able to change the value of the field.
8. Default value: The administrator needs to decide if this field should have a default value when the form is created.
9. Validation: The administrator needs to decide if there are any validation rules that need to be applied to the field, such as a regular expression pattern or a reference qualifier.
10. Journal fields: The administrator needs to decide if this field needs to be tracked for auditing purposes.
11. Help-text: The administrator needs to decide if any additional information should be provided to users when they hover over the field label.

It’s important to consider the impact that these decisions will have on the user experience and the integrity of the data being entered into the system.

Also, if you want to see all fields/dictionary entries in your instance, go to System Definition > Dictionary.

Now that we’ve covered ServiceNow fields, let’s cover a scenario when you’d want to create a dictionary override.

What Is A Dictionary Override? Using the Task Table As An Example

Dictionary overrides also only make sense if you understand parent and child relationships in ServiceNow.

Let’s take the Task table, which is one of 2 base tables in ServiceNow, the other being the CMDB [cmdb_ci] table.

So the task table is the parent table.

And all other task-based tables are child tables, that inherit the properties and most importantly, the fields, of the parent.

So incident, problem, change, etc. are ALL child tables of task.

Say for example that you want the field “Assigned to” on the Incident table to be Mandatory but you don’t want it to be mandatory on the problem or change request tables.

You can’t just go into the dictionary entry and make the dictionary entry on task for “Assigned to” mandatory!

Assigned to is a field on the task table AND on the incident table. You can’t modify the “Assigned to” field on just the incident table, without a dictionary override.

That would make every single “Assigned to” field mandatory for the task tables and child tables extended from task.

So you create a dictionary override, on the parent table, for a field on the child table.

Dictionary overrides allow you to specify a certain condition, usually on a child table, when you don’t want to modify the parent or other child tables.

So in the example above, you would do the following:

Create a new dictionary override record, from the parent table (task), for the incident table (child). And you’d specify that you want to “override” the mandatory field, and then you will populate that boolean that shows up.

This will make the “Assigned to” or whatever field this is for, mandatory.

This will not impact any other field on any other table.

Now when you go to the incident application, “Assigned to” is mandatory – but it wouldn’t necessarily be mandatory on the task, problem or change tables.

Summarizing Dictionary Overrides

In ServiceNow, a dictionary override is just a way to modify the properties of a field in a child table, without modifying the original definition of the field.

This allows an administrator to make changes to a field without affecting other instances of that field or other applications that use that field.

It is most commonly used in parent/child table relationships.

A dictionary override can be applied to any field in a child table, including standard fields and custom fields. Some examples of fields that an administrator may want to override include:

• Changing the label of a field to make it more user-friendly (on a child table)
• Changing the data type of a field to better match the data being entered
• Increasing the maximum length of a text field to accommodate longer input
• Changing the default value of a field to match the organization’s specific needs
• Changing the validation rules of a field to ensure that data is entered correctly
• Changing a field to be read-only,
• Changing the dependent fields to show or hide fields based on certain values.

It’s important to note that, while dictionary overrides can be a useful tool for customizing the ServiceNow platform, they should be tested thoroughly, used sparingly and with caution.

I can only think of a scenario where it makes sense to create a dictionary override on a table where there is a parent / child relationship.

But we’d love to hear from you if you can think of a scenario where creating an override just by itself, on a table with no child tables, makes any sense – as I don’t think this would make much sense.

We are happy to answer any questions you may have in the comments below.