The dictionary defines a field’s type, attributes and defaults, and it is shared across every table that inherits it. A dictionary override adjusts the definition for one child table without changing the base, and enabling audit records a history of changes.
Before you start
You should be comfortable with tables and field types. This article covers the dictionary, overrides and audit.
Step-by-step walkthrough
Step 1: Define the field once in the dictionary
A field’s type, max length, default and mandatory setting live in the dictionary, where they apply to all tables that inherit the field. Changing the base dictionary affects every table, so edits there are high-impact and should be deliberate.
Step 2: Use dictionary overrides for a child table
A dictionary override changes an attribute — say mandatory or default — for one child table without affecting the parent or siblings. It localizes the difference to where it matters, which is safer than a global change.
Step 3: Enable audit where history matters
Auditing records who changed a field, when and to what value, storing it in the audit tables. Enable it on fields where a history is needed, such as state or assignments, and skip it on noisy fields, since audit writes add cost and history volume.
Worked scenario
An override makes a field mandatory only on one table.
Dictionary (task.assigned_to): not mandatory
Dictionary override (incident.assigned_to): mandatory = trueWalk through the example
The base field stays optional for all task tables, while incidents require assigned_to. The change is scoped to the child table, so other tables are unaffected. Auditing the field would record each change, which supports the incident’s history.
Common mistake
Editing the base dictionary when only one table needed the change, which ships unintended behavior everywhere. Another is enabling audit on every field, which bloats the audit tables and slows writes.
Verify the behavior
Confirm the override makes the field mandatory on the child table and optional on the parent. Check the audit history for a changed field and confirm entries appear. Confirm fields without audit have no history.
Interview exercise
Why prefer a dictionary override over a change to the base dictionary?
Answer and reasoning
A base change applies to every table that inherits the field, so it can alter behavior across the platform. An override scopes the change to the single child table that needs it, leaving all other tables unchanged. That reduces the blast radius and makes the exception explicit.
Continue learning
Compare inheritance in Table inheritance and field controls in Reference fields. Read the ServiceNow dictionary documentation and try the ServiceNow interview questions.