Data Dictionary, Dictionary Entries & Table Configuration
Understanding Data Dictionary Entries
The data dictionary servicenow defines the details of every field in the table using sys_dictionary. This entry defines the field types, size, and default behaviour. These dictionary entries servicenow controls the different properties of the field, including:
| Property | Description | Admin Action/Impact |
|---|---|---|
| Display | If set to True for one field, that field’s value is used to represent the record in reference lookups, breadcrumbs, and reports. | Only one field per table can have this set. Typically set on Short Description or Name. |
| Mandatory | Makes the field required; users cannot submit the form without providing a value. | Used to enforce data quality and completeness. |
| Read only | Prevents users from modifying the field’s value, even if they have write access to the table. | Used for system-calculated values or static data. |
| Max length | For String fields, it defines the maximum number of characters allowed. | Default is 40. Crucial for performance; avoid setting an unnecessarily large length. |
Data Dictionary Tables
ServiceNow sys_dictionary is the primary table. The data dictionary in servicenow tables defines the database and provides access to the information on the database schema.
Each of these tables has a unique name and purpose to serve, like:
| Backend Name | Common Name | Purpose |
|---|---|---|
| sys_db_object | Tables | Defines the table itself (Name, Label, Extension). |
| sys_dictionary | Dictionary | Defines the columns/fields on the tables. |
| sys_documentation | Field Labels | Stores the human-readable labels for fields. |
| sys_choice | Choices | Stores the dropdown options for choice fields. |
Dictionary Override
When you extend a table (e.g., an incident extends a task), the child table inherits all the parent table’s fields. But what if you want to customize one of those inherited fields? That’s where servicenow dictionary override comes in.
A dictionary override allows you to:
- Change the field label
- Make the field read-only or mandatory
- Set a different default value
- Change visibility on forms
To configure it:
- Go to System Definition → Dictionary Overrides
- Select the parent field and the child table
- Apply your changes specifically to that child’s table
It is particularly useful when working with extended tables in which some fields must behave differently across child tables.
Configure Label and Choices
Admins often need to change how a field looks or what options it offers without changing the backend database structure.
- Configure Label allows users to change the field’s Display Name. It is stored in sys_documentation, but does not change the backend column name.
- Configure Choices lets users add/remove options in a dropdown menu. It is stored in sys_choice and affects all users. It is a preferred admin action.
Tip: Personalized choices affect only the current user (avoid this).
Working with Choice List
The choice list tables in ServiceNow store all options for dropdown fields in the system. It is a specified field type where users select from pre-defined options. Dependent choices make the choice list dependent on another field. For example, the subcategory options vary by category.
The structure of a choice list:
- Backend Table name: sys_choice
- Label: What the user sees (e.g., “In Progress”).
- Value: What the database stores (e.g., 2 or in progress).
- Sequence: The order they appear in the dropdown.
If the data exists, never change the value of an existing choice. Changing the value breaks historical records, as old records still retain the previous value, making filters and reports inaccurate. It will outcast the historical data, so only change the label.
ServiceNow Reference Qualifiers
ServiceNow Reference Qualifiers are used to filter the records returned in the Reference field’s lookup list. The reference fields store references to fields in another table. It makes the records in reference tables available to the form containing the reference field.
Admins can modify the reference qualifiers:
- For a table and any extended table, by defining the reference qualifiers through Dictionary entry forms.
- On extended tables and their children, using dictionary override reference qualifier servicenow and define a single qualifier per field per form/table.
There are different ways to define reference qualifiers:
- Simple reference qualifiers, using and/or statements to create filters on conditions.
- Dynamic reference qualifiers let you use Create dynamic filter options to run queries against reference fields to filter data sets.
- Advanced reference qualifiers enable admins to define the inline encoded query string. It helps filter directly in the ServiceNow Advanced Reference Qualifier reference qual field.
Final Thoughts
By the end of this module, we will have understood the ServiceNow data dictionary. From data dictionary entries to overrides and reference qualifiers, the chapter highlights field behaviour, table logic, and data filtering.
By focusing on labels, choices, and dependent lists, ServiceNow admins ensured data security and a seamless experience across the platform.
Next Chapter
