ServiceNow Field Types and Dictionary Entries Explained
In ServiceNow, tables are only valid when you define fields that store meaningful data. Whether you’re adding a short description, capturing a phone number, or referencing another record, choosing the right field type is essential.
Beyond just adding fields, it’s equally important to understand how the data dictionary works, because this is where ServiceNow tracks field definitions, behaviours, and metadata. The dictionary entry is what makes each field in a table smart, consistent, and secure.
In this chapter, you’ll explore the different field types in ServiceNow, how to configure them using the sys_dictionary table, and how to use features like dictionary overrides and attributes to customize behavior.
What is a Field in ServiceNow?
A field in ServiceNow is a data container within a table. It holds a specific piece of information, such as a user name, date, priority, or reference to another table.
Each field has:
- A name (the internal system name, e.g., short_description)
- A label (the display name on forms and lists, e.g., Short Description)
- A field type, which determines what kind of data it accepts
Fields are managed and stored through the sys_dictionary table, which forms the core of the ServiceNow data dictionary.
Understanding Field Types in ServiceNow
ServiceNow supports a variety of field types to support different use cases:
Field Type | Purpose |
---|---|
String | Stores short text values (e.g., titles, names) |
Integer | Whole numbers only |
Decimal | Floating-point numbers |
Choice | Predefined drop-down options |
Date/Time | Captures both date and time values |
Reference | Links to another record in a different table |
List | Allows selection of multiple values from another table |
Boolean | True/False (usually displayed as a checkbox) |
Journal | Stores comments or logs, typically for work notes |
Attachment | Allows uploading of files to the record |
For example, a list field type in ServiceNow allows you to select more than one item (e.g., assigning multiple users to a group), while a reference field connects your record to another table, such as linking an incident to a user.
Data Types vs. Field Types
It’s common to confuse data types with field types. In ServiceNow:
- Field type: What you select when creating a field (e.g., String, Choice, Reference)
- Data type: The technical format used in the database to store the value
While ServiceNow handles this behind the scenes, understanding the difference helps when designing tables or integrating with external databases.
How to View and Configure Dictionary Entries?
Every field in ServiceNow is defined and stored as a dictionary entry in the sys_dictionary table.
To view or edit a dictionary entry:
- Right-click the field label on a form
- Select Configure Dictionary
This opens the field’s dictionary record, where you can:
- Change the field’s label or type
- Define default values
- Set field length or precision
- Link to a reference table
- Add dictionary attributes
You can also navigate directly to System Definition → Dictionary to view all entries across the platform.
Dictionary Attributes Explained
Dictionary attributes control field behavior beyond basic settings. These are additional properties you can add to dictionary entries to modify how fields behave in forms, lists, and logic.
Some common ServiceNow dictionary attributes include:
Attribute | Function |
---|---|
max_length | Limits the number of characters for string fields |
ref_auto_completer | Enables auto-complete on reference fields |
choice | Defines how choice fields behave (static/dynamic) |
mandatory | Makes a field required |
default_value | Sets the default input value for the field |
These attributes are added as comma-separated values in the Attributes field of a dictionary entry.
Using Dictionary Overrides
When you extend a table (e.g., incident extends task), the child table inherits all the parent’s fields. But what if you want to customize one of those inherited fields? That’s where dictionary overrides come 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 table
This is especially useful when working with extended tables where some fields need to behave differently across child tables.
Best Practices for Managing Fields
- Always use appropriate field types based on the data you’re storing
- For multiple selections, use a list instead of multiple reference fields
- Use reference fields to link tables instead of duplicating data
- Leverage dictionary overrides instead of duplicating fields in extended tables
- Avoid changing field types after a table has live data—it can cause data loss
- Document your dictionary entries and attributes for future reference or audits
What’s Next?
Now that you understand how fields work and how to manage them through the data dictionary, we’ll move to the next layer: configuring forms and layouts. In the final chapter of this module, you’ll learn how to design clean, user-friendly forms by organizing fields, sections, and related lists.
Next TopicJoin our newsletter: Get daily update on Salesforce career insights & news!
Join Now!
Need more support?
Get a head start with our FREE study notes!
Learn more and get all the answers you need at zero cost. Improve your skills using our detailed notes prepared by industry experts to help you excel.