Table Types & Hierarchy | CIS-DF Part 1

Section 1

Everything is a Table

Before touching any ServiceNow concept, you need one foundational truth burned into your memory: every piece of data in ServiceNow lives in a table. Every incident, every change request, every user, every configuration item, every script, every notification template — all of them are rows in database tables. Even the list of tables itself is stored in a table.

This is not just a technical detail — it is why ServiceNow is so configurable. Because everything is a table, you can add fields to almost anything, create relationships between anything, and report on anything using the same consistent tools. Understanding this single idea unlocks the entire platform.

💡

Analogy — A City of Spreadsheets Imagine ServiceNow as a city of spreadsheets. Each spreadsheet (table) has named columns (fields) and rows (records). When you open an Incident, you're reading row #47382 from the incident spreadsheet. When you add a custom field, you're adding a new column. The "meta-spreadsheet" — a table called sys_db_object — lists every other spreadsheet that exists.

The sys_db_object Table

The table sys_db_object is ServiceNow's "table of tables." It stores one record for every table in the instance — the table name, label, whether it extends another table, which scope it belongs to, and more. When you create a new custom table, a record is inserted into sys_db_object automatically. Navigate here via System Definition → Tables in the Application Navigator.

Section 2

Object-Oriented Inheritance Model

ServiceNow tables use single-table inheritance, borrowed from object-oriented programming. Just as a class in Java can extend a parent class and inherit its methods and properties, a ServiceNow table can extend a parent table and inherit all of its fields, business rules, ACLs, and UI policies.

In concrete database terms: when Table B extends Table A, every row in Table B is also stored in Table A. The row appears in both tables. Table B just adds extra columns on top of the ones inherited from A. This is why querying the parent table returns records from all child tables.

📘

Core Concept — Single-Table Inheritance When incident extends task, every incident record is physically stored in the task table AND has additional columns in the incident table. A GlideRecord query on task will include incidents, changes, and problems. A query on incident shows only incidents. The sys_class_name field on each row identifies the actual type.

sys_class_name — The Type Discriminator

Every record in a table hierarchy has a field called sys_class_name. This stores the actual table name of the record. When an Incident lives in the task table alongside Changes and Problems, ServiceNow uses sys_class_name = 'incident' to distinguish it. Without this field, there would be no way to know which type each row represents.

⚠

Exam Trap — Inheritance Direction Inheritance only flows downward. Child tables inherit from parents — never the reverse. Adding a field to the incident table does NOT add it to task. Adding a field to task immediately adds it to ALL child tables (incident, change_request, problem, etc.). Modifying base/parent tables requires extra caution because changes propagate everywhere.

What Gets Inherited

When a child table extends a parent, it inherits: fields, ACLs (access control rules), business rules, client scripts, UI policies, and dictionary entries. This centralizes governance — one ACL on task protects all work item types. But a mistake on a parent table ACL propagates everywhere, so always test carefully before modifying parent tables.

Section 3

The Task Table — ServiceNow's Core Framework

The task table (task) is the most important table in ServiceNow. It is the parent of essentially every "work item" in the platform. Incidents, Changes, Problems, Service Requests, Work Orders, Cases — they all extend task.

Why does this matter? Because extending task is not just about inheriting fields — it buys you the entire Task Framework. All of these capabilities come for free when you extend task:

SLA Engine — automatic SLA timers with breach notifications and escalation
Approval Engine — approval workflows and approval records
Activity Stream — threaded work notes and comments with full history
Assignment Logic — assigned_to and assignment_group fields with routing rules
State Machine — state field with configurable lifecycle transitions
Watch List — users who receive notifications on the record
Task Relations — parent/child task relationships
Skills-based routing — dispatch logic based on agent capabilities

💡

Analogy — Pre-Built Contract Template Think of task as a standard contract template that already has sections for timeline, approvals, progress tracking, and stakeholder notifications. When you create a new "Work Order" type, you extend this template — you automatically get all those sections without writing them yourself. Creating a standalone table instead is like starting from a blank page: possible, but you lose all the pre-built structure.

Core Tables That Extend Task

incident

Unplanned service interruption. Adds caller_id, impact, urgency, priority auto-calculation.

change_request

Controlled infrastructure modification. Adds change type, CAB approval, risk assessment fields.

problem

Root cause investigation. Adds known_error flag, workaround, fix confirmed date.

sc_request

Service catalog order container. Has child sc_req_item records for each ordered item.

sc_req_item

Individual catalog item within a request. Links to the catalog item definition.

sc_task

Fulfillment task generated from catalog item. Assigned to the fulfillment team.

⚠

Exam Trap — Standalone Table Has No SLAs Creating a custom table that does NOT extend task loses ALL Task Framework features. No SLAs, no approvals, no activity stream, no assignment routing. The exam presents scenarios where a team "creates a standalone table for tracking deliverables" and asks why SLAs are not firing — the answer is always that the table doesn't extend task.

Section 4

Custom Tables — Extending vs. Standalone

When you need a new table in ServiceNow, you face one fundamental decision: extend an existing table, or create a standalone table from scratch. The right choice depends entirely on what the table is meant to hold.

Aspect	Extending Task	Standalone Table
SLAs	Inherited automatically	Must build from scratch
Approvals	Inherited automatically	Must build from scratch
Activity Stream	Inherited automatically	Not available
Assignment fields	assigned_to + assignment_group inherited	Must add manually
State transitions	State machine from task	Must build state logic yourself
Reports across types	Appears in cross-task-type reports	Needs its own reports
Best use case	Anything representing "work" people do	Lookup/reference data, config tables

Custom Table Naming — The u_ Prefix

All custom tables created in the Global scope must have a name prefixed with u_. This prevents naming collisions with ServiceNow baseline tables. For example: u_equipment_request or u_vendor_contract.

Tables inside a Scoped Application use the application's namespace prefix instead. A scoped app with vendor prefix x_fac creates tables like x_fac_facilities_request. The namespace replaces u_ and ensures isolation between vendor applications installed on the same instance.

💡

Tip — When Standalone Is Right Standalone tables are ideal for pure reference and lookup data: country lists, product categories, approved software versions, or configuration parameters. These aren't "work items" — they're data that other records reference. They don't need SLAs or approvals. For anything involving people doing work and tracking progress, always extend task.

Section 5

The cmdb_ci Table — Root of All Configuration Items

Just as task is the root of all work items, cmdb_ci is the root of all Configuration Items (CIs). Every server, application, network device, virtual machine, or database that ServiceNow tracks as a CI is a record in a table that ultimately extends cmdb_ci.

The hierarchy is intentionally deep because different CI types have very different fields. A server needs CPU count, RAM, and OS version. A network device needs port counts and firmware version. The inheritance chain allows each level to add only the fields relevant to that type.

cmdb_ci

Root — all CIs

›

cmdb_ci_hardware

Physical assets

›

cmdb_ci_computer

Computers

›

cmdb_ci_server

Servers

›

cmdb_ci_linux_server

Linux servers

At the root level, cmdb_ci provides universal CI fields that every CI has: name, install status, owned by, managed by, asset tag, serial number, and so on. These appear on every CI regardless of type, because they are inherited.

Why Query Hierarchy Matters

Because of inheritance, querying cmdb_ci returns all CIs — servers, applications, databases, network devices, everything. Querying cmdb_ci_server returns only server-type CIs. This lets you build both broad ("all CIs owned by this department") and specific ("all Linux servers") queries using the same consistent table hierarchy.

Section 6

Database Views — Virtual Read-Only Tables

A Database View in ServiceNow is not a real table. It is a virtual, read-only "table" defined as a SQL JOIN between two or more real tables. Database Views exist primarily for reporting — they let you build reports spanning multiple related tables as if they were one flat table.

📘

Core Concept — What a DB View Actually Is Imagine you want a report showing Incident records alongside details of the CI the incident affected. Incident lives in incident; CI details are in cmdb_ci. A Database View JOINs these two tables on the CI reference field, presenting combined columns as a single virtual table you can report on. No data is duplicated — the view just executes a JOIN query at report time.

Aspect	Real Table	Database View
Can insert records	Yes	No — read-only
Can update records	Yes	No — read-only
Physical storage	Yes — data stored on disk	No — computed on query
Use in reports	Yes	Yes — primary purpose
URL navigation	tablename.list works	viewname.list works
Performance	Fast with indexes	Can be slow (JOIN at query time)

⚠

Exam Trap — DB Views Are Read-Only Database Views cannot be used to insert or update data. If the exam asks how to write records through a Database View, the answer is: you don't. You insert into the underlying real tables. Database Views are query and reporting tools only — never write targets.

Exam Quick Reference

Common Exam Traps — Table Types & Hierarchy

sys_db_object is the "table of tables" — stores every table definition
Child tables inherit from parents — adding a field to a child does NOT affect the parent
Adding a field to a parent table (e.g., task) immediately affects ALL child tables
sys_class_name on every record identifies which actual table/class the record belongs to
Not extending task means no SLAs, no approvals, no activity stream — these come only from the Task Framework
Custom tables in Global scope require the u_ prefix; scoped app tables use the vendor namespace
Database Views are read-only — you cannot insert or update through them
Querying the parent table (e.g., task) returns records from ALL child tables combined
cmdb_ci is the root of all CIs — every CI type extends it directly or through intermediate tables

Exam Checkpoint

Practice Questions

4 questions · Select an answer to see the explanation immediately.

Table Types Quiz 1 / 4

A developer adds a new field to the task table. Which of the following correctly describes the immediate effect?

💡 Explanation

B is correct. ServiceNow uses table inheritance — adding a field to a parent table immediately makes it available on ALL child tables that extend it. A is wrong because the field propagates down; C is wrong because no upgrade is needed; D is wrong because sibling tables share the same parent but inheritance flows parent-to-child, not sideways.