# Tables and Records

> Chapter 4 of the Courseiva SERVICENOW-CSA curriculum — https://courseiva.com/learn/servicenow-csa/tables-and-records

**Official objective:** 1.4 — Describe database tables, records, fields, and the dictionary.

## Introduction

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.

## The Recipe Box Analogy

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.

## Core explanation

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.

## Real-world context

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.

## Exam focus

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.

## Step by step

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.

## Comparisons

### Table vs Record

**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 vs 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 vs Choice Field

**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) vs Extended Table (Incident)

**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

## Diagram

_This diagram shows how the Dictionary defines fields for a Table, which contains Records with Fields, and how Tables like Incident extend from the Task Table, with the sys_id linking Records across the system._

```mermaid
flowchart TD
    A[Dictionary] -->|defines fields for| B[Table]
    B -->|contains many| C[Records]
    C -->|each record has| D[Fields]
    D -->|each field is defined in| A
    B -->|parent table| E[Task Table]
    E -->|extended by| F[Incident Table]
    E -->|extended by| G[Problem Table]
    E -->|extended by| H[Change Request Table]
    C -->|has unique| I[sys_id]
    I -->|links to| J[Other Records]
```

## Common misconceptions

- **Misconception:** A table and a record are the same thing. **Reality:** 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.)
- **Misconception:** The record number (like INC0010001) is the unique identifier the system uses internally. **Reality:** 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.)
- **Misconception:** Fields on a form are stored and defined on the table record itself. **Reality:** 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.)
- **Misconception:** Creating a new table and creating a new application are the same process. **Reality:** 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.)
- **Misconception:** Extended tables are completely independent of their parent table. **Reality:** 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'.)

## Key takeaways

- 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.

## FAQ

**What is the difference between a table and a record in ServiceNow?**

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.

**How do I create a new table in ServiceNow?**

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.

**What is the sys_id and why is it important?**

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.

**Can I change a field from optional to mandatory after data exists?**

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.

**What does it mean that the Incident table extends from the Task table?**

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.

**What is the difference between a reference field and a choice field?**

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.

## Check your understanding

1. **What term describes a single row of data in a ServiceNow table?**

   Answer: A record.

2. **What is the name of the unique identifier automatically assigned to every record in ServiceNow?**

   Answer: The sys_id.

3. **When creating a new table for tracking hardware audits, which table should you extend from to inherit standard fields like Number and State?**

   Answer: The Task table.

4. **Where do you configure whether a field is mandatory or has a default value?**

   Answer: In the Dictionary entry for that field.

5. **What type of field would you use to link an Incident record to the specific User who reported it?**

   Answer: A reference field pointing to the Users (sys_user) table.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/servicenow-csa/tables-and-records