Custom Tables: Where and when to build

[Jake Gillespie]

As a ServiceNow Architect, I'm often asked for advice on the use of custom tables in the Now Platform. If you know what kind of data you wish to manage, the platform makes it very easy to get started. Especially if you're using the Table Builder and App Engine Studio. But before we get into the details, a quick disclaimer!

Custom Table Disclaimer

The creation and usage of custom tables is directly tied to ServiceNow subscription entitlements. The articles I've written in relation to custom tables are based on the ServiceNow Custom Table Guide, which is available via the Legal Schedules -> Entitlement Supplements page. I strongly recommend seeking guidance from the ServiceNow Accounts team as licensing rules, entitlement SKUs, and specific limits can change over time. At the time of writing, this version became effective October 17, 2025.

When Do You Need a Custom Table?

ServiceNow provides an incredibly rich set of OOTB tables designed to handle standard business processes. From Tasks such as Incidents, Cases, or Requests, to foundational data such as Users, Departments, and Locations, or the expansive Configuration Management Database (aka CMDB). However, many organisations have unique data requirements that fall outside these standardised boundaries. Enter the custom table! You may need a custom table if you require:

• Unique Data Scope: Your business process requires capturing specific data points or entities that do not map cleanly into existing OOTB tables.
• Complex Relationships: You need to model relationships between records in ways that standard reference fields cannot accommodate (e.g., many-to-many connections).
• Lookup Data: You have a process that leverages different values mapped together (e.g., approval groups per catalog variable selection).
• External Data Integration: You need a dedicated structure to hold or represent data coming from external systems, whether temporarily (staging) or permanently (remote views).

In essence, if the existing platform tables are too rigid for your unique business logic, custom tables become the necessary architectural tool to give you the flexibility required.

What Exactly Is a Custom Table?
As per the ServiceNow Custom Table Guide, a Custom Table is considered "any non-ServiceNow provided table created or installed by or on behalf of the Customer and used for any purpose". These tables are the foundation upon which custom applications are built, allowing you to define your own data schema using Custom Table Fields (the non-ServiceNow provided fields that capture your specific business information).

You can either build an entirely new table (known as a Base Custom Table), which is not extended from any existing tables, or you can extend a pre-existing table (known as an Extended Custom Table). For example:

• My Custom Data Table [my_custom_table] - a base table to store your business-specific data.
• My Custom Request [my_custom_request] - a table extending from Task [task] to manage your business-specific requests, but inheriting the functionality associated with the OOTB Task table.

Exempt vs. Non-Exempt Tables
The most critical concept in custom table development is understanding licensing and entitlements. Not all customer-created tables are treated equally by ServiceNow’s usage model. We must distinguish between Non-Exempt and Exempt.

1. Non-Exempt Tables (require entitlement)
   Non-exempt custom tables require you to explicitly assign them to a Now Platform App Engine product or an express Custom Table entitlement granted with your subscription.  These are the tables that consume your general Custom Table usage rights and must be accounted for in your licensing plan.
2. Exempt Tables (do not require entitlement)
   Exempt Tables are customer-created tables that, by definition, do not count against your overall Custom Table limit. This exemption is granted to specific types of functionality that ServiceNow deems essential or temporary. The following table types fall under this exemption:
   • Import Set Tables: Extended from Import Set Row [sys_import_set_row], these tables are used to stage data during data imports, acting as temporary holding areas before the data is transformed and moved into a permanent record.
   • Data Lookup Matcher Tables: Extended from Data Lookup Matcher [dl_matcher], these tables help facilitate complex lookups across different datasets within your instance.
   • Many to Many (M2M) Tables: Defined in Many to Many Definition [sys_m2m], these tables are used to manage complex relationships between records.
   • Knowledge Article Tables: Extended from Knowledge Article [kb_knowledge], these tables are used with Knowledge Article Templates.
   • Archive Tables: These tables have names prefixed with "ar_" and are created automatically by the ServiceNow data archiving process, allowing you to retain historical records without impacting active system performance. For example, archived records from the Incident [incident] table are stored in the Archive [ar_incident] table.
   • Remote Tables: Although these tables do not store data in the ServiceNow Database, they are still defined as tables in the platform.

Well, that wraps up my introduction to ServiceNow Custom Tables. If you'd like to know more about any of the above-mentioned types of custom tables, click on each link to see the detailed articles.