Understanding Tables in ServiceNow (Base, Core, Extended & Custom)
If you’re working with ServiceNow, you’re working with tables—whether you realize 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 of ServiceNow. They hold the records, define the fields, and control how data is organized, 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 provides a clear, structured overview of how tables operate, how they relate to one another, and how you can explore them using tools such as the Schema Map.
Introduction to Table
In ServiceNow, a table is a database structure that stores records. 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 of servicenow tables name are:
- The incident table in ServiceNow stores incident records
- The sys_user table stores user profiles
- The sc_req_item table holds catalog request items
You can browse all these using the ServiceNow tables list from the System Definition → Tables module.
Out of the Box Tables
These OOB Tables are pre-installed in the ServiceNow platform. These tables include built-in business logics, workflows, and fields, like:
- Task (task): The parent table for all work-related processes.
- Configuration Item (cmdb_ci): The base table for the CMDB.
- User (sys_user): Stores employee/user details.
- Group (sys_user_group): Stores teams and queues.
- Location (cmn_location): Stores physical addresses/sites.
Before creating a ServiceNow custom table, always check whether OOB tables exist. Using these out-of-the-box tables helps in getting ServiceNow updates and features.
Types of Tables in ServiceNow
ServiceNow supports different kinds of tables to suit different needs:
| Table Type | Description |
|---|---|
| Base Table | Standalone tables that do not extend another table and are the root of the hierarchy. (e.g., cmdb_ci) |
| Core Table | Tables that are part of ServiceNow’s standard application layer, typically extending a base table. (e.g., incident extends task) |
| Custom Table | Created manually by admins/developers for specific use cases |
| Many-to-Many | Tables that link two tables together to relate records from Table A to Table B. used by the platform itself (e.g., sys_user_grmember) |
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 its interactions with the rest of the system.
Table Hierarchy and Extension
Extend tables in ServiceNow follow a parent-child relationship, where one table extends another. It is known as a table hierarchy in servicenow and allows multiple applications to share a common structure.
For example:
- The task table is a base table.
- Tables such as incident, problem, and change_request all extend table in ServiceNow.
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 consistent data across applications.
Types of Fields
ServiceNow table fields support 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/td> |
For example, a list field type in ServiceNow allows selection of multiple items (e.g., assigning multiple users to a group). In contrast, a reference field connects your record to another table—such as linking an incident to a servicenow user table.
Use of Task Table
The task tables in ServiceNow play an important role by providing core ITSM functionality. There are two major use cases of extending the table in servicenow, including:
- Extend Task Table:
- Get free fields such as numbers, priority, state, assignment group, assigned to, and a short description.
- Get free features like SLAs, Approval Engines, and Activity Streams that work seamlessly in tables, extending tasks.
- When Not to Extend Task:
- If the table stores data, it should not be modified, including fields such as office locations, car models, software versions, and others.
What’s Next?
With a basic understanding of the ServiceNow table, the next topic will focus on the schema map and table relationships, including extended and referenced tables.
Next Topic
