What This Table Is
The task table is ServiceNow's master work record table, containing the foundational fields that define any trackable work item in the platform. It stores assignment information, state tracking, timing data, and workflow metadata that every work record type inherits. While you'll rarely create records directly in task, every incident, problem, change request, service request, RITM, and catalog task is fundamentally a task record with additional specialized fields.
The Platform module owns this table as the cornerstone of ServiceNow's work management architecture. It enables the entire ITSM process lifecycle by providing consistent assignment routing, SLA tracking, approval workflows, and state management across all work types. The task table's design allows for unified reporting, cross-process workflows, and shared business rules that apply to all work records regardless of their specific type.
The table hierarchy places task as the parent table extending the base sys_metadata structure. Major child tables include incident, problem, change_request, sc_request, sc_req_item, and sc_task. This inheritance means any Business Rule, Script Include, or ACL targeting task automatically affects all these child tables unless specifically scoped otherwise.
In large enterprise instances, the task table typically contains millions of records spanning multiple years of operational history. This volume makes broad queries against task performance-sensitive, especially when joining across assignment groups or filtering by date ranges. The platform maintains indexes on key fields like assignment_group, assigned_to, and state, but unindexed queries can still cause performance issues.
When You'll Script Against This Table
You'll script against task primarily in Business Rules that need to apply universal logic across all work record types, Script Includes that provide shared task functionality, and Scheduled Jobs that perform maintenance across multiple ITSM processes. Background Scripts often query task for bulk operations or data analysis that spans incidents, problems, and changes simultaneously. Client Scripts rarely target task directly since users interact with specific child tables like incident or change_request.
Access to task records depends on the specific child table's ACL configuration and the user's role assignments. The itil role provides broad read access to most work records, while admin grants full access. Assignment-based security often restricts record visibility to assigned users and their group members, making broad task queries return different result sets depending on the executing user's context.
- Cross-process reporting that aggregates incidents, problems, and changes together
- Universal assignment logic that routes work based on common task fields
- SLA calculations that apply consistent timing rules across all work types
- Workflow activities that need to handle multiple task types in a single flow
- Data cleanup jobs that archive or update old records across multiple ITSM tables
- Integration scripts that sync external systems with multiple ServiceNow work record types
- Custom application development where you need consistent work item behavior
Table Gotchas
Querying task directly returns records from ALL child tables mixed together. Your result set will contain incidents, problems, changes, and requests unless you filter by sys_class_name or use table-specific queries instead.
The state field uses different choice values across child tables. Incident state 6 means 'Resolved' while Change Request state 3 means 'Authorize'. Always check sys_class_name when interpreting state values in mixed task queries.
- The
numberfield auto-generates differently for each child table using separate number formats (INC, PRB, CHG, REQ, etc.) - Assignment group changes trigger complex Business Rule cascades that can cause performance issues on bulk updates
The active field defaults to true but behaves as a string 'true'/'false' in some contexts, causing GlideRecord queries to fail when using boolean true/false instead of string values.
- ACLs on child tables override task-level ACLs, creating security behavior that varies by record type even within the same query result
- Date fields like
opened_atandclosed_atrequire careful timezone handling when querying across global instances
Enjoying this? Get one deep-dive per week.
Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.
Related Tables
The sys_user table connects to task through multiple reference fields including assigned_to, caller_id, opened_by, and closed_by, making user-based queries extremely common. The sys_user_group table links through assignment_group for routing and workload reporting. These relationships drive most task-based dashboard queries and assignment logic throughout the platform.
The cmdb_ci table connects via the cmdb_ci reference field (confusingly named the same as the table), allowing work records to link to affected configuration items. The task_sla table maintains SLA tracking records for each task, connected by the task reference field. Developers frequently join these tables when building performance reports, impact analysis queries, or SLA compliance dashboards that span multiple work record types.
Child tables like incident, problem, and change_request inherit all task functionality while adding specialized fields for their specific processes. When building Script Includes or Business Rules that need to handle multiple work types, developers often query the task table then branch logic based on sys_class_name to access child table-specific fields and behavior.
