Table Inheritance and Extensions

Table Inheritance and Extensions in ServiceNow – A Complete Guide for CAD Exam Preparation

Introduction

Table inheritance and extensions are foundational concepts in ServiceNow application development. Understanding how tables relate to one another through parent-child hierarchies is critical not only for designing robust applications but also for passing the ServiceNow Certified Application Developer (CAD) exam. This guide covers why table inheritance matters, how it works, and how to confidently answer exam questions on the topic.

Why Is Table Inheritance Important?

Table inheritance is one of the core architectural patterns in ServiceNow. Here's why it matters:

- Data Reusability: Child tables automatically inherit all columns (fields) from their parent table, eliminating the need to recreate common fields across multiple tables.
- Consistent Business Logic: Business rules, client scripts, ACLs, and other configurations defined on a parent table can cascade down to child tables, ensuring uniform behavior across related tables.
- Efficient Querying: You can query a parent table and retrieve records from all its child tables in a single query, which is powerful for reporting and list views.
- Scalability: As your application grows, extending tables allows you to add specialized fields and logic without disrupting the existing data model.
- Platform Alignment: ServiceNow's own core tables (e.g., Task, CMDB) rely heavily on inheritance. Understanding this pattern is essential for working effectively with the platform.

What Is Table Inheritance?

Table inheritance in ServiceNow refers to the mechanism by which one table (the child or extended table) derives its structure and behavior from another table (the parent or base table). This is conceptually similar to class inheritance in object-oriented programming.

Key Terminology:

- Base Table: The top-level table in an inheritance hierarchy. For example, the Task [task] table is a commonly referenced base table in ServiceNow.
- Parent Table: Any table that has one or more child tables extending it.
- Child Table (Extended Table): A table that inherits fields, configurations, and behaviors from its parent table. For example, Incident [incident] extends Task [task].
- Table Extension: The act of creating a new child table that inherits from an existing parent table.

Examples of Table Inheritance in ServiceNow:

The Task [task] table is the most prominent example:
- Task [task] (base table)
  ├── Incident [incident]
  ├── Problem [problem]
  ├── Change Request [change_request]
  ├── Service Catalog Request [sc_request]
  │   └── Requested Item [sc_req_item]
  └── And many more...

Similarly, the Configuration Item [cmdb_ci] table has numerous extensions like cmdb_ci_server, cmdb_ci_computer, etc.

How Does Table Inheritance Work?

1. Field Inheritance
When you extend a table, the child table automatically inherits all fields from the parent table. You do not need to recreate these fields. Any new fields you add to the child table are unique to that child (and its descendants). If you add a new field to the parent table later, all child tables will also gain that field.

2. Record Storage
This is a critical concept: records in a child table are stored in both the parent table and the child table. Specifically, the inherited fields are stored in the parent table's database table, while the child-specific fields are stored in the child table's database table. When a record is retrieved, ServiceNow joins the data from both tables. This is why querying the parent table (e.g., Task) can return records from all child tables.

3. Configuration Inheritance
Many configurations cascade from parent to child tables, including:
- Access Control Rules (ACLs): ACLs on a parent table apply to child tables unless overridden.
- Business Rules: Business rules on the parent table fire for child table operations as well, unless specifically restricted.
- Client Scripts & UI Policies: These can also be inherited depending on configuration.
- Dictionary Overrides: Child tables can override specific field attributes (such as default values, mandatory settings, or reference qualifiers) inherited from the parent table without altering the parent's definition.

4. sys_class_name Field
Every table that participates in an inheritance hierarchy has a field called sys_class_name. This field stores the actual table name of the record and is used by ServiceNow to identify which specific child table a record belongs to when querying the parent table. This is what enables the platform to distinguish an Incident record from a Problem record when both are queried from the Task table.

5. Creating a Table Extension
To create an extended table in ServiceNow:
- Navigate to System Definition > Tables.
- Click New to create a new table.
- In the Extends table field, select the parent table you want to extend (e.g., Task).
- Define any additional fields specific to your child table.
- Save the table.

Alternatively, you can choose to create a standalone table (no parent) if your use case does not require inheritance.

6. Dictionary Overrides
Dictionary overrides allow you to customize the behavior of an inherited field on a child table without changing the parent table's field definition. Common overrides include:
- Changing the default value of a field on the child table.
- Making a field mandatory on the child table when it is not mandatory on the parent.
- Changing the reference qualifier for a reference field.
- Modifying read-only settings.

To create a dictionary override: Navigate to the dictionary entry for the field on the child table, or go to System Definition > Dictionary Overrides.

7. Extending vs. Creating a New Standalone Table
You should extend a table when:
- You need to share common fields with other tables (e.g., all task-based workflows benefit from assignment_group, state, priority, etc.).
- You want to leverage existing business logic and configurations from the parent table.
- You need to report across multiple related table types using a single parent query.

You should create a standalone table when:
- Your table has no logical relationship to any existing table.
- You do not need inherited fields or configurations.
- You want complete isolation from other tables' behaviors.

Key Behaviors to Remember:

- Querying a parent table returns records from all child tables (unless filtered by sys_class_name).
- Querying a child table returns only records of that specific type (and its own children, if any).
- Adding a field to the parent table adds it to all child tables.
- Adding a field to a child table does NOT add it to the parent or sibling tables.
- Deleting a parent table record removes the record entirely, including from the child table.
- Business rules on the parent table execute for child table operations unless the business rule is specifically scoped or conditioned otherwise.
- ACLs are evaluated hierarchically – the system checks the child table first, then moves up to the parent if no specific rule is found.

Common Pitfalls and Misconceptions:

- Misconception: Child table records are stored only in the child table. Reality: Inherited fields are stored in the parent table; child-specific fields are stored in the child table.
- Misconception: Business rules on a parent table do not affect child tables. Reality: They do, and this is a frequent source of unexpected behavior.
- Misconception: You can remove an inherited field from a child table. Reality: You cannot remove inherited fields; you can only override certain properties using dictionary overrides.
- Misconception: Table extensions are the same as database views. Reality: They are fundamentally different. Extensions create real parent-child relationships; database views are virtual read-only tables.

Exam Tips: Answering Questions on Table Inheritance and Extensions

The CAD exam frequently tests your understanding of table inheritance. Here are targeted tips to help you succeed:

1. Understand the Task Table Hierarchy
Many exam questions reference the Task table and its children (Incident, Problem, Change Request, etc.). Know which out-of-box tables extend Task and understand why this architecture is beneficial.

2. Know What Gets Inherited and What Doesn't
Fields are always inherited. Business rules and ACLs cascade by default. Client scripts and UI policies can be inherited but depend on the specific configuration. UI actions may or may not apply to child tables. Be precise in your understanding.

3. Focus on Dictionary Overrides
Expect questions about how to change the behavior of a parent field on a child table. The answer is almost always dictionary overrides. Remember that dictionary overrides do NOT change the parent table definition—they only affect the child.

4. Understand sys_class_name
If a question asks how ServiceNow differentiates records of different types in an inherited hierarchy, the answer is the sys_class_name field. This field is automatically populated and is critical for filtering and reporting.

5. Pay Attention to Query Scope
Questions may ask: "If you query the Task table, what records are returned?" The answer: records from Task AND all child tables. Conversely, querying a child table returns only records of that child type (and any of its own children).

6. Know When to Extend vs. Create Standalone
If the exam scenario describes a new application that needs to track assignments, approvals, states, and SLAs—concepts already present on the Task table—the correct answer is to extend the Task table. If the scenario describes something unrelated (e.g., a simple lookup table for colors), a standalone table is appropriate.

7. Be Careful with "All of the Above" Answers
Exam questions on inheritance may list multiple things that are inherited. Remember that fields, business rules, and ACLs are commonly inherited. If the question lists UI pages or modules, those are NOT inherited through table extension—they are separate configurations.

8. Performance Considerations
Deeply nested inheritance hierarchies (many levels of parent-child relationships) can have performance implications due to table joins. While this is less commonly tested, understanding that flat hierarchies are generally more performant can help you eliminate wrong answers.

9. Read Questions Carefully
Some questions may use the terms "extends" and "references" interchangeably in answer choices. These are very different: extending a table creates an inheritance relationship, while a reference field simply points to a record on another table. Do not confuse the two.

10. Practice with Real Scenarios
Before the exam, practice creating extended tables in a Personal Developer Instance (PDI). Create a table that extends Task, add custom fields, create dictionary overrides, and observe how business rules and ACLs behave. Hands-on experience solidifies these concepts far better than reading alone.

Summary

Table inheritance and extensions are a pillar of ServiceNow's data architecture. Child tables inherit fields and many configurations from their parent tables, enabling reusability, consistency, and powerful cross-table querying. Dictionary overrides allow fine-tuning of inherited field behaviors on child tables. The sys_class_name field is the mechanism that distinguishes record types within an inheritance hierarchy. For the CAD exam, focus on understanding what is inherited, how queries behave across parent and child tables, when to use dictionary overrides, and when it is appropriate to extend a table versus creating a standalone one. Mastering these concepts will prepare you well for both the exam and real-world ServiceNow development.