Tables and records. The single most important foundation of the entire ServiceNow platform. Every piece of data you look at, every report you run, every ticket you create lives inside a table as a record, and you cannot understand how to administer the system without first understanding how these pieces fit together like a perfectly organised filing cabinet.
Jump to a section
A simple way to picture Tables and Records
7 recipes are stored in a single recipe box, each one on its own index card. This is exactly how ServiceNow organises its information. Every recipe card has the same fields: a title at the top, a list of ingredients down the left side, and step-by-step instructions filling the rest. Some cards have empty fields — maybe the 'Prep Time' is blank because that recipe is a no-cook dish. Other cards have fields specific to their type, like 'Oven Temperature' only appearing on baking recipes.
When you pull out a single card to read, you are looking at a 'record'. The entire box full of cards is the 'table'. Each blank space on the card — Title, Ingredients, Instructions — is a 'field'. And the master list that defines what fields every card in that box must have is the 'dictionary'.
Now imagine you need to find every dessert that takes less than 30 minutes. Without the index cards being structured the same way, you would have to read every single recipe by hand. ServiceNow tables do this instantly. They force every 'card' (record) to use the same 'fields' so the system can search, sort, and report on data at lightning speed. That is the power of tables and records.
ServiceNow is a database application. At its heart, it is a giant collection of organised data that allows you to track, manage, and automate business processes. Before we talk about tables and records, you need to understand what a database is. A database is a structured collection of information that is stored electronically. Think of it as a digital filing cabinet, but one that is infinitely smarter and faster than any physical cabinet could ever be.
In ServiceNow, that data is organised into 'tables'. A table is a collection of related data that has the same structure. For example, the 'Users' table holds information about every person who has an account. The 'Incidents' table holds information about every reported IT problem. The 'Change Requests' table holds information about planned infrastructure changes. Each table is designed to hold one specific kind of thing.
Inside each table, you have 'records'. A record is a single row of data within a table. If the 'Users' table is the entire filing cabinet drawer for people, then one record in that table is the file for one specific person — say, John Smith. Every record in a given table has the same 'fields'. A field is a single piece of data that describes one attribute of the record. For John Smith, the fields might be: First Name, Last Name, Email, Phone Number, Department, and Role.
Here is where it gets powerful. Because every record in the same table has the exact same set of fields, the system can treat them all uniformly. ServiceNow can sort every user by last name. It can count how many users are in the IT department. It can generate a report showing the number of open incidents by category. None of this would be possible if the data were stored in a messy, unstructured way like a Word document or a pile of sticky notes.
The 'dictionary' is the invisible master blueprint for every table. Technically, it is called the 'Dictionary' in ServiceNow, and it defines every field that belongs to every table. The dictionary specifies:
The field name (e.g., 'short_description')
The type of data the field holds (text, number, date, reference to another table, etc.)
Whether the field is mandatory or optional
The maximum length of the field
The default value, if any
Any rules or constraints (like 'must be a valid email format')
When an administrator creates a new field on a table, they are actually adding a new entry to the dictionary. When a user fills out a form in ServiceNow, the system checks the dictionary to validate every piece of data entered. If the dictionary says the 'Priority' field can only have values from 1 to 5, and someone tries to enter 6, the system rejects it. This keeps the data clean and reliable.
Before ServiceNow, many companies used spreadsheets to track their work. A spreadsheet is essentially a single table with rows and columns. But spreadsheets have major problems: they lack security, they do not enforce data types, they cannot handle multiple users editing simultaneously without version conflicts, and they cannot relate data across different sheets easily. ServiceNow replaces spreadsheets with a relational database — meaning tables can 'relate' to each other through reference fields. For example, an Incident record has a 'Caller' field that references the Users table. That means instead of typing the caller's name as plain text (which could be misspelled), you pick the user from a list, and the system stores a pointer to that user's record. This eliminates duplicate data and ensures accuracy.
There are hundreds of tables in a standard ServiceNow instance. Some are 'base tables' that many other tables extend from. The most important one is the 'Task' table. All work-related tables — Incident, Problem, Change Request, Service Request — extend from the Task table. This means they all inherit common fields like 'Number', 'Short Description', 'State', 'Priority', and 'Assignment Group'. This inheritance is a cornerstone of the ServiceNow data model.
You will frequently hear about 'sys_id' in ServiceNow. Every single record in every table has a unique identifier called the 'sys_id'. It is a 32-character alphanumeric string that is automatically generated by the system when the record is created. You will never type this value manually, but ServiceNow uses it internally to link records across tables. When you see a reference field on a form, it is storing the sys_id of the related record, not the human-readable name.
Understanding tables and records is not optional for the SNOW-CSA exam. It is the foundation upon which every other topic — forms, views, reports, ACLs, business rules — is built. If you do not understand what a table is, you cannot understand how to secure it. If you do not understand what a record is, you cannot understand how to report on it. This is the single most important concept to master before moving on.
Identify the Data Need
You must first decide what kind of data you need to store. Is it information about people (Users), problems (Incidents), or assets (Hardware)? This determines which table you will use or create.
Select or Create a Table
If an existing table fits your data (like Incident for IT problems), use it. If not, create a new table. Always consider extending from an existing table like Task to inherit useful fields automatically.
Define Fields in the Dictionary
For each piece of information you need to capture, define a field. Go to the Dictionary and set the field name, type (text, number, date, reference), mandatory rule, and default value. This step enforces data quality.
Configure Reference Relationships
If your table needs to link to another table (e.g., linking an incident to the user who reported it), create a reference field. Set it to point to the target table so users can select from a dropdown list of valid records.
Test with Real Data
Create a few test records in your table. Fill out every field and verify that mandatory fields block incomplete submissions. Check that reference fields show the correct related records. This confirms your table and dictionary configuration work as expected.
Monitor and Maintain Data Quality
Over time, review the dictionary settings. If users are leaving important fields blank, make them mandatory. If a field is never used, consider deprecating it. The dictionary is a living document that should evolve with the business needs.
Sarah has just been hired as a ServiceNow administrator at a mid-sized company that processes 200 IT support tickets every day. She arrives on Monday morning to find the IT manager frustrated because they cannot get a simple report showing how many high-priority incidents were resolved last week by each technician. Sarah knows this problem exists because the data is not structured properly.
Sarah opens ServiceNow and navigates to the 'Incidents' table. She sees the list of all current incident records. Each incident record has fields like 'Number', 'Short Description', 'Priority', 'Assigned to', 'State', and 'Resolved by'. She notices that some old records have the 'Resolved by' field empty because the previous team sometimes forgot to populate it. Sarah cannot run a reliable report on resolved-by-technician until the data is consistent.
To fix this, Sarah goes to the System Dictionary. She finds the 'Incident' table and locates the 'Resolved by' field. She edits the dictionary entry to make the field 'Mandatory' when the incident state changes to 'Resolved'. She also adds a 'Default Value' of 'Current User' so that the field auto-populates when the record is resolved.
Next, Sarah needs to create a custom table for a new process. The IT manager wants to track 'Hardware Asset Audits' — a list of all physical laptops checked once per quarter. Sarah could create an entirely new table from scratch, but that would be inefficient. Instead, she extends from the 'Task' table so her new table automatically gets all the standard fields like 'Number', 'State', and 'Assigned to'. Then she adds three custom fields specific to audits: 'Asset Tag', 'Audit Date', and 'Audit Result'.
Sarah also needs to ensure that the 'Assigned to' field on her new table correctly links to the 'Users' table. She sets the field type to 'Reference' and points it at the 'sys_user' table. Now when someone fills out the form, they choose a user from a dropdown list instead of typing a name that could be misspelled. - Step 1: Identify the business need (track hardware audits) - Step 2: Extend from an existing table (Task) to inherit common fields - Step 3: Add custom fields in the dictionary (Asset Tag, Audit Date, Audit Result) - Step 4: Configure reference fields to link to related tables (Users, Assets) - Step 5: Set mandatory fields and default values in the dictionary to enforce data quality
Now Sarah can run a report that shows every audit record assigned to a specific technician, grouped by audit result, filtered by date range. The IT manager gets his answer in seconds. The data is clean, consistent, and reliable because the tables and dictionary were configured properly.
This is what a ServiceNow administrator does daily: they design and maintain the data structure so that the rest of the organisation can work efficiently. Without understanding tables, records, and the dictionary, Sarah would be lost.
The SNOW-CSA exam tests 'Tables and Records' in a very predictable way. You will see approximately 5-8 questions on this topic, and they fall into three distinct categories: definition questions, relationship questions, and configuration questions.
Definition questions are the easiest. They directly ask: 'Which term describes a single row of data in a table?' or 'What is the dictionary used for?' The answer pattern is simple: a record is a row; a field is a column; a table is the collection; the dictionary defines the fields. Memorise these four definitions cold.
Relationship questions are trickier. The exam loves to test your understanding of table inheritance and the sys_id. A common question: 'What is the sys_id of a record?' The trap answer choices include 'The record number', 'The short description', 'The user name', etc. The correct answer is 'A unique 32-character identifier automatically generated by the system'.
Configuration questions ask about modifying the dictionary. Example: 'An administrator wants to make a field mandatory when a record reaches a certain state. Where should this be configured?' Wrong answer: 'In the table record'. Correct answer: 'In the Dictionary entry for that field by adding a business rule or a dictionary override'. The exam expects you to know that field-level properties (mandatory, default value, max length) are controlled in the Dictionary, not in the table record itself. - Definition questions: know what table, record, field, and dictionary mean - Relationship questions: understand sys_id as the unique identifier and how tables relate via reference fields - Configuration questions: know that the dictionary controls field properties, not the table record - Inheritance questions: know that Incident, Problem, and Change Request all extend from Task
Another trap the exam uses: mixing up 'table' and 'application'. A table is a data structure. An application is a collection of tables, UI policies, business rules, etc. For example, the 'Incident Management' application contains the 'Incident' table, but they are not the same thing. The exam may ask: 'Which table is extended by the Incident table?' The answer is 'Task'.
You should also know that there are two types of tables in ServiceNow: 'base tables' and 'extended tables'. Base tables (like Task) are top-level parents. Extended tables (like Incident) inherit from a parent. The exam tests whether you recognise that changes to a parent table affect all child tables.
Finally, the exam asks about 'reference fields' versus 'choice fields'. A reference field links to a record in another table (like linking to a user record). A choice field presents a fixed list of options (like Priority: 1-Critical, 2-High, 3-Moderate). They both appear on forms as dropdowns, but they behave completely differently. The exam expects you to distinguish them.
Memorise these exact concepts: sys_id, table inheritance (Task parent), dictionary field properties (mandatory, default, max length), reference vs. choice, and the distinction between a table and an application. These will cover 90% of the questions on this topic.
A table is a structured collection of records, like a spreadsheet tab for a specific type of data.
A record is a single row in a table, representing one item (one incident, one user, one change request).
A field is a single column in a table, representing one attribute (priority, state, description).
The Dictionary is the master definition of every field, controlling data type, mandatory status, and default values.
Every record in ServiceNow has a unique sys_id that the system uses to link records across tables.
Incident, Problem, and Change Request tables all extend from the Task table and inherit its fields.
Reference fields link to records in other tables and store the related record's sys_id, not its name.
A choice field presents a fixed list of options, while a reference field populates from an entire table.
These come up on the exam all the time. Here's how to tell them apart.
Table
A container for many records
Has a name and label
Persists even when empty
Record
A single row of data
Has its own sys_id
Created from a form in the table
Dictionary
Defines field properties
Stored in system tables
Control data rules like mandatory
Table
Groups records of same type
Has a related list of fields
Visible in application navigator
Reference Field
Links to a record in another table
Stores sys_id of related record
Dropdown populates from table data
Choice Field
Presents a fixed list of options
Stores a value from that list
Dropdown does not link to another table
Base Table (Task)
Top-level parent table
Has fields Number, State, Priority
Cannot be deleted if children exist
Extended Table (Incident)
Child table inherits from parent
Adds Impact, Urgency fields
Changes to parent affect this table
Mistake
A table and a record are the same thing.
Correct
A table is the entire collection of rows; a record is a single row within that table.
Beginners hear 'table' and 'record' used loosely and assume they are interchangeable, but they are distinct containers vs. items.
Mistake
The record number (like INC0010001) is the unique identifier the system uses internally.
Correct
The sys_id is the true unique identifier; the record number is a human-friendly display value that can be changed.
The visible number looks like a unique identifier, so beginners naturally assume it is the primary key, but the exam tests the sys_id concept.
Mistake
Fields on a form are stored and defined on the table record itself.
Correct
Fields are defined in the Dictionary, not on the table record. The table record just groups the fields.
When an administrator opens a table record and sees a 'Fields' related list, it looks like the table owns the fields, but the actual definition lives in the Dictionary.
Mistake
Creating a new table and creating a new application are the same process.
Correct
A table is a data structure; an application is a container for tables, modules, and other components. Creating a table does not create an application.
The ServiceNow UI offers both 'New' and 'New Application' options, leading beginners to confuse the two concepts.
Mistake
Extended tables are completely independent of their parent table.
Correct
Extended tables inherit all fields and properties from the parent table. Changes to the parent affect children.
Beginners think 'extended' means 'separate', but in ServiceNow, it means 'inherits from'.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A table is the entire container like a spreadsheet tab. A record is a single row inside that table. For example, the Incident table holds every incident; one specific incident with number INC001 is a record.
Navigate to System Definition > Tables in the application navigator. Click 'New' and fill in the table name, label, and optionally choose a parent table to extend from. Then add fields via the Dictionary.
The sys_id is a unique 32-character identifier automatically assigned to every record in every table. It is used by ServiceNow internally to link records across tables and perform database operations.
Yes, you can update the Dictionary entry for the field to make it mandatory. However, existing records with that field left blank will not be retroactively validated. You will need to fix those records manually or via a script.
It means the Incident table inherits all fields from the Task table (like Number, State, Priority) and then adds its own incident-specific fields (like Impact, Urgency). Any change to the Task table affects Incident automatically.
A reference field links to a record in another table (like linking to a User record). It stores the sys_id of the related record. A choice field presents a fixed list of options (like Priority levels) and does not link to another table.
You've finished Tables and Records. Continue through the SNOW-CSA study guide to build a complete picture of the exam.
Done with this chapter?