› CIS-DF Hub › Part 1 › Schema Design Patterns
⬡ Part 1 · Topic 4

Schema Design Patterns

Good schema design prevents technical debt. Learn when to extend vs. create tables, how scoped apps isolate data, when table-per-type is better than a single table, and the patterns ServiceNow itself uses for configuration and lookup data.

📋 5 sections ⏱ ~18 min read 🎯 ~8% exam weight 🏷 Data Model
Section 1

Extend vs. New Table — The Decision Framework

Every new data requirement in ServiceNow starts with the same question: should I extend an existing table, or create a new standalone one? Getting this wrong creates long-term pain — missed framework features if you don't extend when you should, or an overly complex hierarchy if you extend when you shouldn't.

Ask these questions in order:

  1. Does this represent work that people do? (tickets, tasks, approvals) → Extend task
  2. Does this represent a physical or logical thing in IT? (server, app, service) → Extend cmdb_ci
  3. Does this extend a more specific existing type? (a kind of incident, a kind of server) → Extend that type's table
  4. Is this purely reference/lookup data? (categories, locations, vendors) → Standalone table
  5. Is this configuration data for your app? (settings, rules, policies) → Standalone table
🚫
Anti-Pattern — Extending Just for Inheritance Don't extend a table just to inherit a few fields you want. If you extend incident to create a new "Facility Request" just because you want the state field, you now have Facility Requests appearing in all Incident reports and SLA rules. Only extend a table when your new record type is genuinely a specialization of the parent type.
Section 2

Scoped Applications and Table Isolation

A Scoped Application is a container for all the components (tables, scripts, UI, workflows) that belong to a specific application. Every table, script, and configuration item created within a scope belongs to that scope and is isolated from other scopes by default.

Think of scopes as namespaces: they prevent name collisions and ensure that changes in one application don't accidentally break another. A scoped app with vendor prefix x_acme creates tables like x_acme_project and x_acme_deliverable. No other app can accidentally create a table with those same names.

Global vs. Scoped

AspectGlobal ScopeScoped Application
Table namingMust start with u_Uses app namespace prefix (x_vendor_)
Script accessCan access all tables/scriptsRestricted by cross-scope access policies
Upgrade safetyMay conflict with upgradesIsolated — upgrades don't touch scoped code
Store publicationCannot publish to StoreCan be published to ServiceNow Store
Best forInstance-specific customizationsReusable apps, products, integrations
⚠
Exam Trap — Scoped Access Restrictions Scripts in a Scoped Application cannot access Global scope tables or scripts by default. Access must be explicitly granted via Application Cross-Scope Access policies. If a scoped app's script tries to query a Global table it doesn't have access to, it receives an empty result — not an error. This silent failure is a common debugging trap.
Section 3

Configuration Tables Pattern

One of the most common patterns in ServiceNow development is the Configuration Table pattern. Instead of hard-coding rules or values in scripts, you store them in a configurable table. This separates "what the app does" (code) from "how it is configured" (data), making the system more maintainable and giving admins control without needing developer access.

For example, instead of writing a Business Rule that has a hard-coded list of assignment groups for each category, you create a table u_routing_rule with fields for Category and Assignment Group. The Business Rule then queries this table. Now admins can add, remove, or change routing rules by editing table records — no script changes needed.

💡
Tip — System Properties Are Also Configuration Tables ServiceNow's own System Properties (sys_properties) follow this same pattern. Rather than hard-coding values in scripts, the platform stores configuration values as records in sys_properties. Your custom apps should follow the same convention — use gs.getProperty('your.property.name') to retrieve configuration values.
Section 4

Lookup / Reference Data Tables

Lookup tables (sometimes called "reference data tables") are standalone tables that exist purely to provide values that other tables reference. They typically have just a Name field and a few descriptive fields. Examples: countries, languages, product lines, priority levels, or service categories.

The advantage over Choice fields: lookup table values can be edited by administrators without touching the data dictionary. Adding a new choice to a dropdown field requires a developer with dictionary access. Adding a new row to a lookup table is a simple form save that any admin can do.

AspectChoice FieldLookup Table + Reference
Adding new valuesRequires dictionary edit (developer)Add row to table (admin)
Additional metadataLabel/value onlyCan add as many fields as needed
Referential integrityNone — choice deleted = orphaned dataReference link — can detect/prevent orphans
Cross-table useDefined per-field, per-tableSame lookup table referenced from many tables
Suitable forSmall, stable sets (5-15 values)Larger, growing, or metadata-rich sets
Section 5

Schema Upgrade Safety

ServiceNow upgrades (new platform releases) update baseline records — Business Rules, ACLs, Dictionary entries, and Scripts that ship with the platform. Understanding which customizations are upgrade-safe is essential for maintaining a healthy instance.

  • Custom fields (u_ prefix) — 100% upgrade safe. Upgrades never modify custom-prefixed fields.
  • New custom tables — 100% upgrade safe. Upgrades never delete custom tables.
  • New business rules / scripts — Safe if the name doesn't conflict with a baseline record being added.
  • Modifications to baseline records — Flagged as "customer modified." The upgrade may skip re-applying the ServiceNow change, leaving you running old logic.
  • Dictionary modifications on baseline fields — Risky. If ServiceNow changes the baseline definition, your change may be overwritten or cause conflicts.
⚠
Exam Trap — Baseline Modifications Directly modifying a ServiceNow baseline Business Rule or ACL marks it as "customer modified." During upgrades, ServiceNow will flag these and in many cases will NOT overwrite your changes — meaning you miss security patches and bug fixes. Best practice: never modify baseline records. Instead, create a new Business Rule that runs in addition, or use a higher-order override.
Exam Quick Reference

Common Exam Traps — Schema Design

  • Extend task when building "work items" — standalone tables lose SLAs, approvals, activity stream
  • Extend cmdb_ci (or its children) for any CI type you need to track
  • Scoped app tables use x_vendor_ prefix; Global custom tables use u_
  • Scoped scripts cannot access Global tables without explicit Cross-Scope Access grants
  • Configuration Tables (storing rules as records) are preferred over hard-coded values in scripts
  • Lookup/reference tables scale better than choice fields when values change frequently or carry metadata
  • Modifying baseline records risks missing upgrade patches — create new records alongside instead
  • Custom fields with u_ prefix are never touched by platform upgrades
Exam Checkpoint

Practice Questions

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

Schema Design Quiz 1 / 4

A scoped application needs to store IT asset records. Which table should its custom CI table extend to ensure proper CMDB integration?

💡 Explanation

C is correct. Any CI type should extend cmdb_ci or one of its subclasses to participate in CMDB Health, IRE, and Discovery. task is for work items. sys_metadata is for platform metadata. A standalone table would be disconnected from all CMDB tooling.

A developer in Global scope creates a custom table. What naming requirement applies to custom fields added to that table?

💡 Explanation

B is correct. Custom fields in the Global scope must use the u_ prefix (e.g., u_custom_field). This ensures platform upgrades never overwrite custom fields. Scoped app fields use the vendor namespace prefix (e.g., x_vendor_). There is no standard x_ or c_ prefix for Global custom fields.

A scoped application script needs to read data from a Global-scope table. What configuration is required?

💡 Explanation

B is correct. Scoped scripts cannot access Global-scope tables or APIs without an explicit Cross-Scope Access grant. This is a deliberate isolation boundary in the ServiceNow scoped application model. A is incorrect — access is not automatic. C and D are not valid solutions for cross-scope access.

An admin plans to modify a baseline (out-of-box) record in a ServiceNow application to customize its behavior. What is the primary risk?

💡 Explanation

B is correct. Modifying baseline records risks having the customization overwritten during platform upgrades. Best practice is to create new records alongside baselines rather than modifying them. Custom fields with u_ prefix and scoped customizations are upgrade-safe. A, C, and D are not consequences of modifying baseline records.

Score: 0 / 4
Part 2: Import Sets Architecture →