sc_task Table — ServiceNow Reference

Table Reference/sc_task

The sc_task table stores catalog fulfillment tasks created from Requested Items (RITMs) in the Service Catalog module. It extends the task table and represents the actual work items that fulfill catalog requests. Before querying, understand that these records have complex state flows and automatic assignment rules that differ from standard tasks.

What This Table Is

The sc_task table stores catalog fulfillment tasks that represent the actual work required to deliver requested catalog items. When a user submits a catalog request, the system creates a Requested Item (RITM), and that RITM spawns one or more sc_task records to handle the fulfillment workflow. These tasks bridge the gap between what users request and the technical work required to deliver it.

Owned by the Service Catalog module, this table supports the end-to-end catalog fulfillment process. The workflow typically flows: Catalog Request → Requested Item (RITM) → Catalog Task(s) → Fulfillment → Closure. Each sc_task represents a discrete piece of work, such as provisioning software, creating accounts, or shipping hardware.

The table extends task, inheriting all standard task fields like state, assignment_group, and assigned_to. No tables extend sc_task in the base system, making it a leaf table in the task hierarchy. The critical relationship is with sc_req_item through the request_item reference field.

In large enterprises, this table can contain millions of records with high daily transaction volumes. Performance characteristics depend heavily on proper indexing of request_item and state fields. The table supports the full audit trail of catalog fulfillment, making it critical for compliance reporting and fulfillment metrics.

When You'll Script Against This Table

You'll script against sc_task in Business Rules for automatic assignment and state transitions, Script Includes for catalog fulfillment logic, Workflow activities for approval routing, and Scheduled Jobs for SLA monitoring. Client Scripts handle form behavior and field dependencies, while UI Actions provide custom fulfillment operations.

Access requires catalog_admin or itil roles for full CRUD operations. Fulfiller groups get filtered access based on assignment. The catalog role provides read access to assigned tasks only.

Common scripting patterns:

Auto-assign tasks based on catalog item or requested for location
Update parent RITM state when all child tasks complete
Calculate SLA deadlines based on catalog item fulfillment times
Copy variable values from parent RITM for fulfillment context
Generate approval records for high-value or sensitive requests
Create follow-up tasks or change requests for complex fulfillments
Send notifications to stakeholders at key fulfillment milestones

Table Gotchas

⚠️

The state field uses different choice values than standard tasks. sc_task uses states like 'Open' (1), 'Work in Progress' (2), 'Closed Complete' (3), and 'Closed Incomplete' (4), not the incident/problem state values.

⚠️

Tasks automatically inherit the requested_for user from their parent RITM, but assignment logic often ignores this. Always check assignment_group and assigned_to rather than assuming requested_for determines ownership.

The request_item field is mandatory and cannot be changed after creation - tasks are permanently tied to their parent RITM
Variables are stored on the parent RITM, not the task - use request_item.variables dot-walking to access request details

⚠️

Closing all sc_task records for a RITM doesn't automatically close the RITM. You need explicit Business Rules or Workflows to handle parent state management based on child task completion.

Performance trap: avoid queries without state or request_item filters on large instances - these fields are indexed for optimal performance
ACL gotcha: users can see tasks for items they requested even if they lack general task table access, but this doesn't extend to scripting contexts

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.

The parent task table provides the foundational fields and behavior for assignment, state management, and work notes. Understanding task table patterns is essential for effective sc_task development, especially for SLA and approval integrations.

The most critical relationship is with sc_req_item (Requested Items), which contains the catalog item details, variables, and user context. Developers constantly join these tables to access request specifics for fulfillment logic. The sc_request table (Catalog Requests) provides the top-level request container, while sc_cat_item defines the catalog item configuration and fulfillment groups.

Standard reference relationships include sys_user for assignment and requester tracking, sys_user_group for fulfillment team assignment, and cmn_location for location-based routing. Integration scenarios often involve change_request for changes triggered by catalog fulfillment and cmdb_ci for asset provisioning and configuration item updates.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
request_item	reference	Request Item	References the parent sc_req_item record. This relationship cannot be changed after task creation and determines variable access and context.
state	choice	State	Task state using catalog-specific values: 1=Open, 2=Work in Progress, 3=Closed Complete, 4=Closed Incomplete. Different from standard task states.
cat_item	reference	Catalog Item	References the sc_cat_item that generated this task. Inherited from parent RITM but useful for direct catalog item queries and fulfillment group lookups.
assignment_group	reference	Assignment Group	Fulfillment team responsible for this task. Often populated automatically based on catalog item configuration or assignment rules.
assigned_to	reference	Assigned To	Individual fulfiller assigned to complete this task. Can be set manually or through auto-assignment Business Rules.
requested_for	reference	Requested For	End user who will receive the catalog item. Inherited from parent RITM and cannot be changed on the task level.
opened_by	reference	Opened By	User who originally submitted the catalog request. Often different from requested_for in scenarios where someone requests items for others.
cmdb_ci	reference	Configuration Item	Links to the configuration item being provisioned or modified. Crucial for asset lifecycle management and automated provisioning workflows.
location	reference	Location	Delivery or installation location for the request. Inherited from requested_for user but can be overridden for shipping and fulfillment routing.
business_service	reference	Business Service	Business service impacted by this fulfillment task. Used for service mapping and business impact analysis during fulfillment activities.
priority	choice	Priority	Task priority typically inherited from catalog item or calculated based on requester VIP status. Values: 1=Critical, 2=High, 3=Moderate, 4=Low, 5=Planning.
due_date	glide_date_time	Due Date	Expected completion date for fulfillment. Often calculated automatically based on catalog item SLA definitions and request submission time.
work_notes	journal_input	Work Notes	Internal fulfillment notes visible to fulfillment team only. Used to track progress, issues, and coordination between fulfillment groups.
short_description	string	Short Description	Brief task description often auto-populated from catalog item name and requested_for user. Format typically: '[Catalog Item] for [User]'.
description	string	Description	Detailed task description including fulfillment instructions. May contain variable values or custom instructions from the catalog item definition.
approval	choice	Approval	Approval status if this task requires approval workflow: not requested, requested, approved, rejected. Links to sysapproval_approver records.
made_sla	boolean	Made SLA	Indicates whether task was completed within SLA timeframe. Calculated field that updates when task closes based on due_date comparison.
calendar_integration	choice	Calendar Integration	Enables Outlook calendar integration for scheduling fulfillment activities. Values control calendar event creation and synchronization behavior.
correlation_id	string	Correlation ID	External system correlation identifier for integration scenarios. Used to track fulfillment status across multiple systems and orchestration tools.
user_input	journal_input	User Input	Input from the requester visible to both fulfillment team and requester. Used for additional requirements or clarification during fulfillment.

Common Queries

Get all active catalog tasks

// Most basic query - active tasks not yet closed
var gr = new GlideRecord('sc_task');
gr.addQuery('state', 'IN', '1,2'); // Open, Work in Progress
gr.orderBy('opened_at');
gr.query();

while (gr.next()) {
    gs.info('Task: ' + gr.number + ' for ' + gr.requested_for.getDisplayValue());
}

Find open tasks for specific assignment group and catalog item

// Filter by state, assignment group, and catalog item
var gr = new GlideRecord('sc_task');
gr.addQuery('state', '1'); // Open state
gr.addQuery('assignment_group', 'hardware_fulfillment_group_sys_id');
gr.addQuery('cat_item.name', 'Laptop');
gr.orderBy('priority');
gr.query();

while (gr.next()) {
    gs.info('Open laptop task: ' + gr.number + ' - Priority: ' + gr.priority.getDisplayValue());
}

Get overdue tasks for SLA breach notification

// Real-world scenario: find tasks breaching SLA for escalation
var gr = new GlideRecord('sc_task');
gr.addQuery('state', '!=', '3'); // Not closed complete
gr.addQuery('state', '!=', '4'); // Not closed incomplete  
gr.addQuery('due_date', '<', gs.nowDateTime()); // Past due date
gr.addQuery('made_sla', 'false');
gr.orderBy('due_date'); // Oldest overdue first
gr.query();

gs.info('Found ' + gr.getRowCount() + ' overdue catalog tasks requiring escalation');

Count tasks by state for dashboard metrics

// Aggregate count by state for reporting dashboard
var ga = new GlideAggregate('sc_task');
ga.addAggregate('COUNT');
ga.groupBy('state');
ga.addQuery('opened_at', '>=', gs.beginningOfLastMonth()); // Last month only
ga.query();

while (ga.next()) {
    var state = ga.state.getDisplayValue();
    var count = ga.getAggregate('COUNT');
    gs.info('State: ' + state + ', Count: ' + count);
}

Wrong way vs right way to access request variables

// WRONG: Variables are not on sc_task table
// var taskVar = gr.variables.laptop_model; // This fails!

// RIGHT: Access variables through parent RITM
var gr = new GlideRecord('sc_task');
gr.get('task_sys_id_here');
if (gr.isValidRecord()) {
    // Dot-walk to parent RITM to access variables
    var laptopModel = gr.request_item.variables.laptop_model;
    gs.info('Requested laptop model: ' + laptopModel);
}

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

sc_task