Table extension and the task model
Quick answer
How table inheritance works, what extending task gives you, and when a standalone table is the better choice.
Key takeaways
- Extend task when you need task behaviour, not by habit
- A query on the parent returns every child row
- Reference and configuration tables should stand alone
- Keep hierarchies shallow, two levels is usually enough
Inheritance basics
An extended table inherits every field, business rule, ACL and UI policy from its parent, and adds its own. Incident extends task, which extends nothing. Rows live in the parent table structure, so a query on task returns incidents, problems and changes together.
What you inherit from task
Number, assignment group, assigned to, state, priority, approvals, SLAs, work notes and the activity stream. If your process needs those, extend task. If it is reference data such as a list of buildings, do not.
When not to extend
Extending brings the parent along for the ride.
- A pure reference table should extend nothing so it stays small and fast
- Extending task adds task business rules that may not apply
- Deep hierarchies make queries and reports harder to reason about
- Custom tables that extend nothing are easy to move between scopes
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
What does a table that extends task inherit?
- A. Only fields
- B. Fields, business rules, ACLs and UI policies
- C. Only the number field
- D. Nothing until you configure it
Show answer
B. Fields, business rules, ACLs and UI policies
Extension inherits configuration as well as columns.
Best structure for a simple list of office locations?
- A. Extend task
- B. Extend cmdb_ci
- C. Standalone table extending nothing
- D. Extend sys_user
Show answer
C. Standalone table extending nothing
Reference data needs none of the task behaviour.