Understanding Tables and Schema in ServiceNow

If you’re working with ServiceNow, you’re working with tables—whether you realise it or not. Every time you create an incident, update a user profile, or submit a request, you’re interacting with data stored in a table.

Tables form the core structure behind everything in ServiceNow. They hold the records, define the fields, and control how data is organised, extended, and connected across the platform. Without a solid understanding of how ServiceNow tables work, building scalable and maintainable solutions becomes nearly impossible.

This chapter gives you a clear, structured look into how tables operate, how they relate to one another, and how you can explore them using tools like the Schema Map.

What are Tables in ServiceNow?

In ServiceNow, a table is a database structure in which records are stored. Think of it as a spreadsheet, with one row being a record and each column being a field. ServiceNow tables integrate tightly into the platform’s logic, UI, automation, and security processes, unlike spreadsheets. Behind every module or application you use, there is a table in the background managing that data. A few examples are:

• The incident table in ServiceNow stores incident records
• The sys_user table stores user profiles
• The sc_req_item table holds catalogue request items

You can browse all these using the ServiceNow tables list from the System Definition → Tables module.

Key Components of a Table

Each ServiceNow table is made up of several parts that define how data is stored and presented:

• Table Label: A human-readable name, like Incident
• Table Name: The actual system name, like incident
• Fields: The individual data points in the table (e.g., short description, assigned to)
• Column Name: The internal name of each field
• Field Type: Defines the kind of data allowed (string, reference, choice, date, etc.)

You can view and modify field settings using the dictionary entries, which control everything from field type to visibility.

Types of Tables in ServiceNow

ServiceNow supports different kinds of tables to suit different needs:

When you create a custom table in ServiceNow, you decide whether it should stand alone or extend an existing table. It affects the fields it inherits and how it interacts with the rest of the system.

Table Hierarchy and Extension

Many ServiceNow tables follow a parent-child relationship, where one table extends another. It is known as a table hierarchy and allows multiple applications to share a common structure.

For example:

• The task table is a base table
• Tables like incident, problem, and change_request all extend the task table

It means they automatically include fields like:

• Assigned to
• Priority
• Short description
• State

If you open a table record under System Definition → Tables, you’ll see an “Extends Table” field. It tells you which parent table (if any) the current table inherits from.

Understanding the hierarchy is key to avoiding redundant designs and ensuring your data is consistent across applications.

Common Tables You’ll Work With

Here’s a list of some frequently used ServiceNow tables and their purposes:

It is only a small portion of the full ServiceNow tables list, which you can view in the platform to explore available options for your specific use cases.

Understanding Table Relationships

Tables in ServiceNow are rarely isolated. Most are linked using reference fields, allowing you to connect one table’s data to another.

Example relationships:

• The Caller field in the incident table points to the user table
• The Assignment Group field connects to the sys_user_group table

These links define the table relationships that allow for advanced reporting, automation, and process logic.

In more complex cases, you’ll encounter many-to-many relationship tables, where one record is connected to multiple records in another table. These are often used in access control, CI relationships, and service mapping.

Using the Schema Map

The ServiceNow schema map is a visual tool that helps you understand how tables are connected through extensions, references, and relationships.

How to see the schema map in ServiceNow:

1. Go to System Definition → Tables

2. Open the table you want to examine (e.g., incident)
3. Click Schema Map

It opens an interactive diagram showing:

• Tables that extend the current table
• Tables referenced by fields
• Tables that reference the current one

It is one of the best ways to understand how data flows between tables, especially when designing custom applications or debugging complex setups.

Exporting Table Schema

If you need to export the table schema—for documentation, review, or planning—you can do so using built-in platform features:

• Use the Dictionary to export a table’s field structure
• Export table lists as Excel or XML for review
• Use scripts to programmatically export schema data (for advanced cases)

While there’s no “one-click schema exporter,” combining dictionary and list views allows you to share table structures with teams or clients efficiently.

What’s Next?

Now that you understand how tables work, the next step is learning how to create and extend tables in ServiceNow. In the next chapter, we’ll walk through how to build new tables from scratch, decide whether to extend existing ones, and follow best practices to keep your design clean and scalable.

Next Topic