ServiceNow's table inheritance means querying a child table like incident automatically gives you access to all parent table fields from task, while querying the parent task table returns records from ALL child tables. This isn't JOIN behavior — it's true inheritance where child tables physically extend parent schemas. Most developers expect separate tables and get confused when an incident query includes number and state fields that "belong" to the task table.

When to use this

  • When you need both parent fields (number, state) and child-specific fields (priority, category) in a single query
  • When building reports or integrations that work across multiple task-based tables with shared logic
  • When you need to process all task types (incident, change_request, problem) uniformly using common parent fields
  • When implementing business rules or scheduled jobs that operate on table hierarchies

When NOT to use this

  • Don't query the parent task table when you only want specific child records — use direct child table queries instead
  • Don't use this for performance-critical queries with large datasets — inheritance queries are slower than direct table access
  • Don't access child-specific fields when querying the parent table — use getTableName() to check record type first
  • Don't use this in client-side scripts — table inheritance doesn't work in GlideRecord client-side, use GlideAjax instead

Key behaviors and gotchas

  • Querying incident returns only incident records but gives access to all task table fields like number, state, assigned_to
  • Querying task returns ALL records from incident, change_request, problem, and any other task-extending tables
  • Use gr.getTableName() to identify which child table each record belongs to when querying parent tables
  • Child-specific fields (priority on incidents) return empty when accessed on wrong record types from parent queries
  • ACL evaluation happens at the record level — parent table ACLs don't automatically grant child table access
  • Indexes exist on both parent and child tables — querying by child-specific fields is slower when done through parent table
⚠️

Never assume field availability when querying parent tables. A task query might return a change_request record that doesn't have incident-specific fields like priority or category. Always check getTableName() or use isValidField() before accessing child-specific fields.

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