Build the data model

  • Release version: Xanadu
  • Updated August 1, 2024
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Build the data model

    This guide explains how to create and configure tables and fields to support your application’s data model in ServiceNow. It emphasizes best practices for table creation, field selection, and data normalization to ensure consistent, maintainable, and scalable data structures within your ServiceNow instance.

    Show full answer Show less

    Key Features

    • Automatic Fields: Every new table created in ServiceNow automatically includes five system fields—Created by, Created, Updated by, Sys ID, and Updates—that track metadata and uniquely identify records.
    • Table Extension: New tables can inherit fields and functionality by extending existing tables, with the task table being the most commonly extended. This allows reuse of common structures and behaviors.
    • Field Types: ServiceNow offers many field types with built-in validation. Choosing the correct type supports data integrity and usability. Common types include Integer, Currency, Phone number, Reference, Choice, Date, Date/Time, and String.
    • Reference Fields vs. Choice Lists:
      • Reference fields link to records in another table using sysid, enabling data normalization and consistency, especially for data shared across records (e.g., users).
      • Choice lists provide predefined name/value pairs for selection, suitable for fields with fewer than ten static options.
    • Best Practices for Data Consistency: Avoid using String fields for data that can be normalized, such as user names. Instead, use Reference fields to ensure consistent data and improve reporting and automation.
    • Field Management Guidelines:
      • Do not change field types after creation.
      • Check for existing inherited fields before adding new ones to extended tables; override the label if needed.
      • Review existing tables and exempt tables before creating new ones to leverage existing structures and comply with platform guidelines.

    Practical Application for ServiceNow Customers

    By following these guidelines, you can design a robust data model that supports your application’s requirements with consistent, validated data. Leveraging table extension and appropriate field types ensures efficient reuse of platform capabilities and simplifies maintenance. Choosing between reference fields and choice lists based on the number and nature of options will improve user experience and data quality. This approach also facilitates better automation and decision-making through normalized and reliable data.

    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.

    Table 1. Fields added to every 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.

    Add fields to the table to support the data model required by the application. ServiceNow has many different field types with built-in validation. Select the field type that best fits the field’s data.
    Note:
    String (plain text) fields are the easiest to configure. However, because users can enter anything, string fields can result in bad and inconsistent data that is difficult to use.

    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.

    Do not use a string field for users' names. It increases the chance of errors.

    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.

    Use reference fields for users' names for consistency

    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.

    While a reference field can normalize data, other fields can be used for specific types of data. The ServiceNow Documentation site has the complete list of Field types. Some common field types are:
    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.
    Note:
    Field types should not be changed after a field is created.

    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.

    Choice lists do not require a reference table and are easier to configure than reference fields. Use Choice lists when the field has ten or fewer options and the options will not change. Consider using a reference field and table when:
    • 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.
    When using reference fields, review the tables available in the instance to reference before creating a table. If creating a new table, check the list of exempt tables in section 2 of the Custom Table Guide. If appropriate, extend the new table from one of these.
    Note:
    Before creating new fields on an extended table, check for an existing field inherited from the base table that has a similar purpose. If a field is found, override the extended table's label.