How to Create Tables and Columns in ServiceNow (Beginner-Friendly Guide)

BillMartin · 2 hours ago

If you’re building anything in ServiceNow, you’re going to end up working with tables and columns. They’re where your data lives. No tables means no place to store records, and no columns means no way to capture the details you care about.

This walkthrough assumes you already have access to a developer instance. That could be your company’s dev environment, or a Personal Developer Instance (PDI) like the one commonly used for learning and testing. A PDI is useful because it’s your own lab. You can experiment, break things, and reset your approach without risking real work.

Before you start: what you need ready

You don’t need much to follow along, but a couple basics help:

A ServiceNow developer instance (company dev or PDI)
Comfort moving around the left navigation (the Application Navigator)
A basic understanding that a table stores records, and fields (columns) store values

If your instance is new, that’s fine. Developer instances often come with demo data, which makes learning easier.

Why tables and columns matter in ServiceNow

Think of a ServiceNow table like a spreadsheet tab, or a database table. Every row is a record. Every column is a field. When you open a form and see fields like Short description, Assignment group, or Caller, you’re looking at columns in a table.

A good example is Incident Management, which comes with ITSM in many developer instances. When you open an Incident record:

The form you’re viewing is tied to the Incident table
The values you see on the form are stored in columns on that table
The list view (a list of incidents) is basically table rows displayed in a grid

Once you see the Incident table in action, it’s easier to understand what you’re building when you create your own custom table.

Two ways to find a table in ServiceNow

ServiceNow gives you more than one path to the same place. That’s helpful when you’re learning, because sometimes it’s faster to jump to the table from a record, and other times it’s better to start from the System Definition area.

Method 1: Jump to the table from a record

If you’re already looking at a record (like an Incident), you can get to the table settings from the form.

Open a record, such as an Incident
Click the record number (the clickable identifier on the form)
Go to the top-left context menu
Select Configure, then choose Table

That takes you directly to the table definition for the record you’re viewing.

This is also where you start noticing how ServiceNow is structured.

What you learn from the Incident table

When you view the Incident table definition, you’ll see that Incident inherits from Task. This is a big deal in ServiceNow.

It means:

Incident automatically gets fields from Task
Those inherited fields include common record tracking details (created, updated, and related audit-type behavior)
You can still add Incident-specific fields on top of what you inherit

This setup reflects a standard pattern: tables usually aren’t isolated. They often build on a base table so you don’t have to reinvent common record behavior.

Method 2: Use the Tables module (System Definition)

You can also go straight to the full table list.

In the Application Navigator, type table
Under System Definition, select Tables

You’ll see a list of tables and (often) what they extend. This makes it easier to explore what exists in your instance and how tables relate.

If you search for “incident” here, you’ll land back on the Incident table definition, just through a different door.

Understanding parent-child relationships with the Schema Map

When you open a table definition and scroll down, you’ll find the schema map. This gives you a visual view of how tables relate to each other.

This view helps you spot two important things:

Inheritance (parent-child tables): Incident extends Task, so it sits under Task in the hierarchy.

References (links to other tables): You’ll also see where the Incident table points to other tables. A common example is referencing the user table, so you can select a user when you set fields like Caller or Assigned to.

In the tutorial, the user table is referred to as the platform user table (commonly sys_user). One quick hint you’ll see in practice: when something doesn’t have the custom prefix, it usually means it’s a platform table that comes with ServiceNow.

The schema map gives you a “bird’s-eye view” of your data model. When you start creating your own tables, it becomes your sanity check. It helps you confirm you built what you meant to build.

Table design choices you should make before you create anything

Creating a table is not just a click-and-done action. You’re setting the foundation for your app.

Before you hit New, make sure you’re clear on a few points.

1) Which application scope should the table live in?

Every table belongs to an application scope. You’ll see this on the table definition.

If you’re building inside:

Global, the table lives in the Global scope
ITSM, the table is tied to the ITSM application
Your own custom application, the table stays inside that app

You want to decide this early, because it affects how you package, move, and manage your work later.

2) Should the table extend a parent table?

Extending a parent table means you inherit its fields and behavior. Not extending means you start from a simpler base.

In the video, you’re encouraged to try both approaches:

Create a table with no parent (a basic custom table)
Create a table that extends Task (to see inheritance in action)

This choice matters because it connects to how you’ll model relationships and reuse standard fields.

3) How will this table relate to other tables?

As soon as you add reference fields, you start shaping relationships. Those relationships might be:

One record pointing to one record in another table (common with Reference fields)
One-to-many patterns (one parent record has many child records)
Many-to-many patterns (handled through additional relationship tables)

You don’t need to solve all of that on day one, but you should at least know what the table is for.

Hands-on: create a custom “Movies” table in ServiceNow

Now you’re ready to build.

Create the table

From System Definition > Tables:

Click New
Enter a label, for example: Movies
Keep the scope as Global for a simple setup
Save the table (in the tutorial, this is done with right-click, then Save)

Because it’s a custom table, ServiceNow adds a custom prefix to the table name to show it’s not a base platform table. This is the normal behavior in ServiceNow and helps separate custom work from out-of-box tables.

Decide whether to create a module

During table creation, you may be asked if you want to create a module. A module is what shows up in the left navigation, so you can click into your table easily.

If you choose Yes, ServiceNow adds a module entry for the table
If you untick it, the table still exists, but you won’t get the automatic navigation item

This doesn’t change how the table stores data, it only changes how easy it is to access from the menu.

Notice the “best practice” fields that appear

Once your table is saved, ServiceNow adds standard behaviors and tracking features that support audit needs. You don’t have to build all that by hand. It’s part of why starting with the platform is faster than building a database from scratch.

Add columns (fields) to your custom table

A table without columns is like a form with no questions. You can create records, but you can’t store anything meaningful.

In the tutorial, you add two example columns to the Movies table: one string field and one reference field.

Column 1: Movie Name (String)

Create a new field (column) with these ideas:

Label: Movie Name
Type: String
Max length: set based on what you need (the tutorial demonstrates using a small number first, like 10)

The key point is that length matters. If you set very large lengths everywhere “just in case,” you waste space. That can affect performance and storage over time.

If you later decide 10 is too short, you can adjust the max length. In the video, you see an example of setting a max length like 32.

Column 2: Buyer (Reference to User)

Next, you add a field that points to a user.

Label: Buyer (or Ticket Buyer)
Type: Reference
Reference table: the user table (commonly sys_user)

This is one of the most common patterns in ServiceNow. A reference field lets you store a link to another table’s record. On the form, it looks like a lookup field where you can search and select a user.

This is where relationships start to show up in the schema map. Once you add a reference to sys_user, your table now has a direct connection to the platform’s user records.

Important table settings to review after adding columns

After you create the table and fields, take a minute to look through the table settings.

Max length and field sizing

You already saw how max length affects memory and storage. Keep your sizes realistic. If most movie names will fit in 32 characters, set 32. If you need more, increase it for a reason, not by habit.

“Extensible” (can your table be a parent?)

ServiceNow lets you mark a table as extendable, which means it can become a parent table later.

If you set Extensible = true, you’re saying: “Other custom tables can extend this table.”

That’s useful when you’re designing a bigger app with multiple related record types. If this is a one-off table, you may not need it, but it’s still worth understanding.

Table access and security (preview)

You’ll also see options related to who can read from the table and who can’t. This is part of access control in ServiceNow.

The tutorial calls out that this topic goes deeper, and it’s usually covered under:

ACLs (Access Control Lists)
Table access controls (permissions at the table level)

For this post, the key is simple: you can create the table and fields first, then return later to lock down access once you know who should use the data.

Common mistakes to avoid when creating ServiceNow tables

A few problems show up often when you’re new:

Creating tables in the wrong scope: If you plan to build an app, keep your data in that app scope. Don’t default to Global unless you mean it.

Not thinking about inheritance early: Extending Task can be helpful, but it also brings complexity. Don’t extend a parent table just because it exists.

Making every string field huge: Field length is not free. Choose sizes with intent.

Skipping relationship planning: If you’ll need users, groups, or related records, plan those reference fields and relationships early so your data model stays clean.

Conclusion

When you know how to create a table and add columns in ServiceNow, you control the structure of your app’s data. You learned how to find tables, understand inheritance through Task and Incident, use the schema map to spot relationships, and build a custom Movies table with both string and reference fields. You also saw why scope, field length, and table extensibility matter before you go too far.

If you want to keep practicing, create a second table and try extending a parent table like Task, then compare the fields you get automatically. If you get stuck, write down what you expected to happen, then check the schema map to confirm what you built.