Forms & Lists

Create a New Table in ServiceNow

Custom tables let you store data that doesn't map to any existing ServiceNow table structure. When you're done, you'll have a new table with auto-generated forms, lists, and access controls that integrates cleanly with the platform.

When you need a custom table

Most data in ServiceNow fits into existing tables — incidents, changes, users, configuration items. But sometimes you need to track something completely different: vendor contracts, office locations, training certifications, or business-specific entities. Before custom tables, teams would either force-fit data into inappropriate tables (storing contracts as incidents) or maintain separate spreadsheets that couldn't integrate with workflows. Platform administrators own custom tables, but they're usually requested by business teams who need structured data that ServiceNow workflows can access.

How table inheritance shapes your design

Every ServiceNow table can extend another table, inheriting its fields and behaviors. Start with the base sys_db_object table for simple data storage, extend Task for anything workflow-related (you get state, assignment, approval features), extend Configuration Item for assets you want in the CMDB, or extend sys_metadata for configuration data that moves between instances. The inheritance choice matters more than the initial fields — you can add fields anytime, but changing inheritance later means rebuilding the table. ServiceNow auto-creates forms, lists, application menus, and basic ACLs, so you get a working interface immediately.

Building production-ready tables

A basic table works for testing, but production tables need proper naming (u_ prefix for global scope, x_yourcompany_ for scoped apps), sensible display values, and custom fields that match your data model. Add dictionary overrides for required fields, field validation, and reference qualifiers. Create custom forms that group related fields logically rather than using the auto-generated layout. Set up proper ACLs beyond the defaults — most custom tables need role-based read/write restrictions that the auto-generated rules don't provide.

Before you start

  • admin role or table_admin role
  • Understanding of your data model and required fields
Sourdough
Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher
Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview
Tasks
CMDB
API
Metrics
Monitor
Internals
Instance:sourdoughdev·Version:Yokohama
Instance StateONLINE
System StatusFully Operational
Session Timeout90 minutes
Logged-In Sessions2 (20 active)
Build Nameyokohama-12-18-2024_p1
IP Address10.159.128.43
Instance HealthHealth Score: 90%
🔥 5dSourdough (Chrome Plugin)Dark Mode

Step by step

1

Navigate to Tables definition

Go to System Definition > Tables. This is where all ServiceNow tables are defined, including custom ones you create. The list shows existing tables with their inheritance hierarchy and basic properties.

2

Create the new table record

Click New to create a table definition. Set Label to your business-friendly name (like "Vendor Contracts"). The Name field auto-populates with the technical name — for global scope, it adds the u_ prefix automatically (u_vendor_contracts). Choose this carefully since changing it later requires rebuilding the table and updating all references.

TIP

If you're in a scoped application, the prefix changes to x_yourscope_ automatically.

3

Configure table inheritance

Set Extends table to define inheritance. Leave empty for basic data tables, choose Task [task] for workflow-enabled tables that need states and assignments, choose Configuration Item [cmdb_ci] for assets, or choose Application File [sys_metadata] for configuration data. Inheritance determines which fields and behaviors your table gets automatically — Task tables inherit state, assigned_to, approval workflows, and activity streams.

TIP

Extending Task is the most common choice for business data that needs workflow capabilities.

4

Set display and access options

Check Auto number to generate unique identifiers automatically (recommended for most tables). Set Accessible from to define where users can access this table — Configuration for admin-only tables, or the appropriate application menu for business users. Check Extensible if other tables might inherit from this one later. Click Submit to create the table.

5

Configure the display value

After the table creates, you'll see it in the Tables list. Open your new table record and find the Display field. Change this from "Number" to a field that makes sense as the primary identifier — typically a name or title field you'll add. This controls how records appear in reference fields and lists.

TIP

You can set this to a concatenated field like "number + short_description" for more context.

6

Add custom fields

In the related lists at the bottom, click New in the Dictionary Entries section to add fields specific to your data model. Each field gets a Column label (what users see), Column name (database field name), and Type (string, reference, choice, etc.). Add your core business fields now — you can always add more later.

7

Test the auto-generated components

Navigate to your table using the application menu (or directly via [instance].service-now.com/[table_name]_list.do). ServiceNow automatically created a list view, form view, application menu module, and basic ACLs. Create a test record to verify the form works and displays your fields correctly. Check that the display value appears properly in the list.

Best practices

  • Always use descriptive table labels and field names — six months later, "u_data_table" tells you nothing about what it stores.

  • Don't extend Task unless you actually need workflow features like assignment and approvals — it adds complexity and unused fields.

  • Set the Display field to something meaningful before creating many records — changing it later doesn't update existing reference displays automatically.

  • Create tables in scoped applications rather than global scope when possible — it makes change management and deployments much cleaner.

  • Test your table inheritance choice early by creating sample records — switching inheritance later means losing data and recreating integrations.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue