Explain Dictionary entries and overrides in ServiceNow

In ServiceNow, the system dictionary is a table which is known as Dictionary entry that includes the details for each table and every column definition on each table in an instance.

Each row in the ServiceNow system dictionary displays either a table or a column within one of the tables. Moreover, the system dictionary provides options for administrators to alter the tables and fields. These as a result define lists and forms.

The Dictionary overrides within ServiceNow allow system administrators to define certain field configures on an extended table diversely from those on the parent table. Besides, this doesn’t affect the parent table or its extension tables. The dictionary overrides are explained in the dictionary entry record for the field on the parent table in ServiceNow.

Moreover, in dictionary overrides the administrators can override the following aspects of a field in extended tables:

· Reference qualifiers

· Dictionary attributes

· Default values

· Calculations

· Field dependencies

· Default column display values

· The mandatory and read-only status

Servicenow training provides users with the flexibility to customise\design forms so that they can mirror their business processes. But sometimes repairing with default values can be tricky.

Dictionary override examples ServiceNow

Let’s discuss a few examples to better understand the Dictionary override in ServiceNow:

Ex 1: Override Reference Qualifier

Within an OOB ServiceNow instance, the task.assigned_to the field includes a source qualifier of roles=itil. This means that when a user goes to pick an allotted one to on an Incident, Alter, Problem, etc, it will only present users that have the ITIL role.

Although, for Problems, the user only wants to allot problems to a new role he made called problem_coordinator.

In this condition, if he just adjusts the task.assigned_to reference qualifier, he will adjust it for all the related tables. So users must use a reference qualifier as a substitute.

Ex 2: Override the Default value

Hereunder, the dictionary entry for task.contact_type is a phone. Although on Change Management, the user has decided to use the Contact Type field. He doesn’t like it to default to the phone.

In that case, he would like to build a dictionary override, because he doesn’t need it to affect incident management.

Example 3: Override Display value

In this example, the display values are used in Reference fields and other places in ServiceNow. This useful to “describe a record” much faster with a field as a substitute of the sys_id it stores.

Moreover, the work table uses a task number as the standard value. However on a modified request if the user wants to use Short Description as the display value. Then he can use a dictionary override in that case.

How to write dictionary override in ServiceNow

Using a dictionary override allows a field within a child table to have a different value rather than the same field in the main table. For example, a dictionary override modifies the standard value of the priority field from 4 in the parent table to 5 within the Incident table.

About this task

The dictionary overrides are available for tables that only support extended tables. Besides, the user has the option to only add dictionary overrides upon tables that are in the purview of the parent table.

Process

· Go to System Definition -> Dictionary.

· Now, open the record for the field given.

· Within the Dictionary Overrides related list, click on the New.

· Fill up the fields on the form, as relevant.

Change Dictionary Entries

The users have the option to change dictionary entries by setting up a field on a form or from the Dictionary module.

To change the dictionary entries, follow the below steps:

· Go to a field within a form-> do Right-click on the field -> select Configure Dictionary or display <field name>. Now, the window system dictionary entry for the field opens.

· Now go to System Definition –> Dictionary-> and click on an entry for a field or table. Here opens the Entries for tables have Type set to Collection.

· Then -> update the dictionary entry fields with relevant details.

· Finally, Click on the Update button.

In ServiceNow, the Dictionary Entry form was designed to give an “Advanced view” and with additional fields. The user might need to configure the form to look over all fields. The form includes the following fields to fill-up;

· Table

· Type

· Active

· Function Field

· Read-only

· Audit

· Text Index

· Column Label

· Column Name

· Maximum Length

· Mandatory

· Display

· Attributes (Adv View)

Moreover, it also includes the default value, reference specification, dependent field, choice list, calculated value, UI Action; add value, and the related list.

ServiceNow reference qualifier JavaScript if

The reference qualifiers are a powerful tool that every ServiceNow administrator and consultant should include in his toolbox. They allow them to dynamically filter the options within a reference field available.

Here in this topic of Advanced Reference Qualifier, I would like to specifically mention how to leverage a Script Include substitute of a global Business Rule to run the qualifier script.

Up to the present, the only way to get Advanced Reference Qualifiers to work was to build a global business rule to run the said script. Besides, it works great, but the results of a global script get loaded all the time when it isn’t important. Moreover, this is not something that affects any real issues in practice. But it could affect performance issues if used to the extreme level.

The best practice instruction for advanced-level reference qualifiers should be to use a Script Include. It is instead of a global Business Rule to run the qualifier script. The usage of Script Include means that the script only gets loaded and used when the user actually needs to use it. Furthermore,, we will see how this can be performed using a common example of filtering the ‘Assignment group’ to display only groups for the ‘Assigned to’ value.

The first part is the ‘Reference qual’ field value on the dictionary entry of the reference field. The ‘javascript:’ prefix is the similar one, but the user needs to refer his Script Include function as a substitute of the business rule function.

javascript:u_backfillAssignmentGroup();

The on-demand functions will only work if the user makes sure that the name of his script matches with the name of his function correctly.

function u_backfillAssignmentGroup() {

var gp = ‘ ‘;

var a = current.assigned_to;

//return everything if the assigned_to value is empty

if(!a)

return;

//sys_user_grmember has the user to group relationship

var grp = new GlideRecord(‘sys_user_grmember’);

grp.addQuery(‘user’,a);

grp.query();

while(grp.next()) {

if (gp.length > 0) {

//build a comma separated string of groups if there is more than one group

gp += (‘,’ + grp.group);

}

else {

gp = grp.group;

}

}

// return Groups where allocated to is in those groups we use IN for lists

return ‘sys_idIN’ + gp;

}

Summing Up

Thus, the above words present the dictionary entries and dictionary overrides within ServiceNow. Moreover, these are the tables that include each table detail in an instance of the table. Moreover, they are based on the extension tables under a parent table. There are many uses of these dictionaries over the ServiceNow platform and its users. To get more insights, go through the best servicenow online training.