What This Table Is

The sys_db_object table is ServiceNow's core metadata registry that defines every table in your instance. It stores the fundamental properties that make a table exist: its internal name, display label, inheritance relationships, and behavioral flags. This is the authoritative source for table definitions that the platform uses to render forms, build queries, and enforce data model rules.

Owned by the Platform module, this table supports the entire data model foundation of ServiceNow. Every table you see in the Tables & Columns module has a corresponding record here. The super_class field creates the extends hierarchy that drives table inheritance throughout the platform.

This table extends sys_metadata, making every table definition a metadata object with update sets and scope tracking. Child tables include wf_workflow and other specialized metadata tables that need additional table-specific properties.

In a large enterprise instance, expect 8,000-15,000 records here. The table is heavily cached and indexed, but queries filtering on super_class or complex nameSTARTSWITH operations can still impact performance during metadata operations.

When You'll Script Against This Table

You'll primarily script against sys_db_object in Script Includes and Business Rules that need to dynamically inspect table definitions or build table hierarchies. Discovery scripts query this table to determine if target tables exist before attempting to populate them. Schema validation utilities use it to verify table inheritance before performing data migrations.

Read access requires admin role or higher. Global scope scripts can read any table definition, but scoped applications see limited records based on their scope configuration. Writes are restricted to security_admin role.

  • Build dynamic table pickers that show only tables extending a specific parent
  • Validate table existence before performing GlideRecord operations
  • Generate reports showing custom table usage across business units
  • Implement governance checks that prevent table creation without proper naming conventions
  • Build utilities that traverse table inheritance hierarchies for data archival
  • Create schema documentation generators that map table relationships
  • Implement scope-aware table discovery for integration patterns

Table Gotchas

⚠️

The `name` field stores the internal table name, not the label users see. Always query by `name` field when checking if tables exist programmatically.

  • The super_class field is empty for base tables like task, but contains table names (not sys_ids) for extended tables
⚠️

Filtered queries with `nameSTARTSWITH` on table prefixes can timeout in large instances. Use exact matches or `name` IN queries when possible.

  • The is_extendable flag being false doesn't prevent extension via API or import - it only controls UI options
  • Records here are automatically created when you create new tables - you rarely insert directly into sys_db_object
⚠️

Scoped applications only see their own tables plus global tables. Cross-scope table validation requires elevated privileges.

  • The number_ref field links to the number series definition, but many tables don't use auto-numbering so it's frequently empty
Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime

Related Tables

This table extends sys_metadata, inheriting scope tracking, update set integration, and version control capabilities. The parent relationship means every table definition flows through update sets and can be moved between instances as customizations.

You'll commonly join with sys_dictionary to get complete table schemas, sys_ui_section to find form layouts, and sys_ui_list for list view configurations. The sys_number table connects via number_ref to provide auto-numbering sequences for tables that use them.

Schema inspection workflows typically query both sys_db_object and sys_dictionary together - the first gives you table-level metadata like inheritance and naming, while the second provides field-level details. Access control scenarios often need sys_security_acl records to understand which tables have custom security rules.