Build the data model
Summarize
Summary of Build the data model
This guide explains how to create tables and fields in ServiceNow to support an application’s data model, highlighting best practices and key considerations for efficient and consistent data management.
Show less
Key Features
- Automatic Fields: ServiceNow adds five default fields to every new table—Created by, Created, Updated by, Sys ID, and Updates—that track record metadata automatically.
- Table Extension: New tables can extend existing tables to inherit fields and functionality, with the task table being the most commonly extended. This facilitates reuse and consistency.
- Field Types: ServiceNow supports various field types with built-in validation, including Integer, Currency, Phone Number, Reference, Choice, Date, Date/Time, and String. Selecting the appropriate type is critical for data integrity.
- Reference vs Choice Fields:
- Choice fields offer a predefined list of fewer than ten options and are simple to configure.
- Reference fields point to records in other tables, storing sysid values to normalize data, ideal for dynamic or complex lists, or when multi-level dependencies exist.
- Data Normalization: Use reference fields instead of string fields for data like user names to ensure consistent and normalized data across records.
- Field Management: Avoid changing field types after creation and check for existing inherited fields before adding new ones on extended tables. Override labels as needed to maintain clarity.
- Agentic AI Assistance: Consider using agentic AI to help build and edit applications, streamlining the development process.
Practical Guidance for ServiceNow Customers
- Leverage table extension to build on standard or existing tables rather than creating new tables from scratch when possible.
- Choose reference fields for user-related data and other relational data to ensure data consistency and enable richer integration.
- Use choice lists for simple, static option sets with fewer than ten items for ease of configuration.
- Before creating new tables or fields, review existing tables and fields to avoid duplication and take advantage of standard structures.
- Manage choice lists carefully and consider if the field values impact business logic, such as decision tables in Flow Designer.
- Utilize the built-in validation of field types to reduce data entry errors and improve data quality.
Create tables and fields on the tables to support the application’s data model.
ServiceNow automatically adds five fields to each new table. The new fields contain auto-populated information about the table.
| Field name | Database name | Description |
|---|---|---|
| Created by | sys_created_by | User who created the record. |
| Created | sys_created_on | Date/time when the record was created. |
| Updated by | sys_updated_by | User who last updated the record. |
| Sys ID | sys_id | Unique identifier for the record. It is unique throughout the instance. |
| Updates | sys_mod_count | Numeric field that counts the number of updates to the record since record creation. |
New tables can extend an existing table to inherit fields and functionality from the table being extended. Add to and modify the components of the extended table. The most commonly extended ServiceNow table is the task table. For more information, see When to create a new table vs. when to extend and Exploring ServiceNow AI Platform® tables.
In the example, a string field type is used for a user's name. Notice the Caller field is different for each Incident record, but the caller may be the same person. Do not use a string field type for a user's name in tables.
Instead, use a reference field type that references the User table instead of a String field. Users then need to select a single consistent record in the Caller field.
Reference fields ensure consistent data by normalizing date in another table in ServiceNow. ServiceNow has over 2000 baseline tables available to reference. The Appendix lists some commonly used tables for building an app.
| Field type | Descriptions |
|---|---|
| Integer | Stores number values and can be used in calculations. |
| Currency | Holds a currency value and will show values in the currency of the logged in user. |
| Phone number | Includes validation and formatting for E164-compliant phone numbers. |
| Reference | Displays a record from another table and helps to normalize data. |
| Choice | Displays a select box with a predefined list of choices. Choice lists should include fewer than ten items. |
| Date | Stores a date value selected with a date picker. Use Date if you do not need a specific time. |
| Date/Time | Stores date and time values selected with a date and time picker. Use Date/Time to compare specific times or if the exact time is important. |
| String | Holds freeform text. Use String if no other field type matches the values stored in the field. |
Choice lists or reference fields
Choice lists and Reference fields both offer users a way to choose a value from a list. Choice lists are name/value pairs. Users select from the names and the field stores the value of the selected choice. Scripts use the value. Add and remove name/value pairs from the choices to manage the list of options.
Reference fields point to a table. Manage choices in the table. The value stored in the reference field is the sys_id of the referenced record.
- The field requires more than ten choices.
- The choices will regularly change.
- Someone other than an administrator needs to manage the choices.
- The value of the field has an impact on decision logic. For example, decision tables in Flow Designer.
- The data has multi-level dependencies between different fields that can lead to complex and unwieldy choice field combinations.
- The choices require more than a name/value pair. For example, referencing a user record gives the referencing table access to other user details, such as email and department.
- A table already exists that includes the data needed for the field.