sc_request Table — ServiceNow Reference

Table Reference/sc_request

The sc_request table stores Service Catalog orders and acts as the parent record that groups related catalog items (RITMs). Owned by the Service Catalog module, it extends the task table and drives the entire catalog fulfillment workflow from order placement through approval and delivery.

What This Table Is

The sc_request table stores Service Catalog orders—the parent record that ties together everything a user ordered in a single shopping cart session. When someone orders multiple catalog items (like a laptop, software license, and parking pass), ServiceNow creates one sc_request record and multiple child sc_req_item (RITM) records underneath it.

This table extends task, inheriting all task fields like state, assigned_to, and priority. The Service Catalog module owns this table and uses it to orchestrate the entire order lifecycle—from initial submission through approval workflows, fulfillment tracking, and final delivery confirmation.

The sc_request drives state management for the entire order. While individual RITMs can have different states (one approved, another waiting for approval), the parent request aggregates these states to show overall order progress. The stage field tracks high-level workflow phases like 'Waiting for Approval' or 'Fulfillment', while state provides granular status details.

In large enterprises, this table sees heavy volume—thousands of new records daily during onboarding seasons or hardware refresh cycles. Each record typically exists for weeks or months as orders move through approval chains and fulfillment processes. The table performs well at scale, but complex queries joining multiple child RITMs can become expensive without proper indexing strategy.

When You'll Script Against This Table

You'll script against sc_request primarily in Business Rules (especially on RITMs that need to update parent state), Script Includes for catalog workflows, and Scheduled Jobs for SLA monitoring. Catalog Client Scripts rarely touch this table directly—they work with the catalog item forms that eventually create the request. Flow Designer actions frequently query this table to route approvals or trigger notifications.

Access is controlled by standard catalog security plus the catalog role for administrative operations. Users can see their own requests, approvers can see requests awaiting their approval, and catalog admins see everything. Cross-scope access works normally—requests created in global scope are accessible from scoped apps with proper ACLs.

Common scripting patterns:

Business Rules on sc_req_item that query the parent request to update aggregated fields
Scheduled Jobs that find overdue requests and escalate or send reminder notifications
Script Includes for approval workflow logic that need to check request-level conditions
Reporting scripts that aggregate spending, request volume, or fulfillment metrics by department
Integration scripts that sync order status to external procurement or asset management systems
Portal widgets that display 'My Orders' dashboards with request summaries and RITM breakdowns
Flow actions that route requests to different approval chains based on cost thresholds or item types

Table Gotchas

⚠️

The state field inherits from task but uses catalog-specific state values (1=Draft, 2=Waiting for Approval, 3=Approved, etc.). Don't assume standard task states.

⚠️

request_state is a separate field from state—it's a choice field that mirrors state values but as strings. Scripts often query the wrong one.

The price field stores the total cost of all RITMs, but it's calculated—don't set it directly. Updates happen automatically when child RITM prices change.
Queries on requested_for are fast (indexed), but joining to child RITMs in the same query can be expensive. Query the request first, then get RITMs separately.

⚠️

The approval field points to the latest approval record, not all approvals. Use approval_history or query sysapproval_approver separately for complete approval chains.

Business Rules on this table fire for every RITM state change because RITMs update their parent request. Performance-sensitive rules should check current.operation() and exit early for unnecessary updates.

💡

Use GlideAggregate on this table for reporting—it handles the large record volumes better than looping through individual records.

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 task table is the parent—all task functionality like assignments, work notes, and SLAs work here. The sc_req_item table contains the child records that represent individual catalog items within each request. This parent-child relationship is the core of catalog order management—you'll constantly join between these tables.

The sys_user table connects through requested_for and opened_by for user lookups. The sysapproval_approver table tracks approval workflows, and you'll often query both together to build approval status dashboards. The sc_cat_item table defines the catalog items being ordered, connected through the child RITMs.

For reporting and integration work, you'll frequently join with sys_user_group (through user department fields), cmn_cost_center for financial tracking, and cmdb_ci when catalog items create or modify configuration items during fulfillment.

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
state	integer	State	Catalog request state (1=Draft, 2=Waiting for Approval, 3=Approved, etc.). Different values than standard task states.
request_state	choice	Request State	String version of state field ('submitted', 'approved', 'closed_complete'). Often confused with the integer state field.
stage	choice	Stage	High-level workflow stage ('Request Submitted', 'Waiting for Approval', 'Fulfillment'). Aggregated from child RITM stages.
requested_for	reference	Requested for	User receiving the catalog items. Can differ from opened_by when someone orders on behalf of another user.
opened_by	reference	Opened by	User who submitted the catalog order. Inherited from task table but critical for catalog security and approvals.
price	currency	Price	Total cost of all RITMs in this request. Calculated field—updates automatically when child RITM prices change.
delivery_address	string	Delivery address	Where physical items should be delivered. Inherited by child RITMs but can be overridden at item level.
special_instructions	string	Special instructions	User-provided delivery or setup instructions. Appears on RITM fulfillment tasks and approval forms.
approval	reference	Approval	Points to the most recent approval record only. Use approval_history or sysapproval_approver for complete approval chains.
approval_history	glide_list	Approval history	Comma-separated list of approval record sys_ids. Better than approval field for tracking multi-step approval workflows.
approval_set	reference	Approval set	Groups related approvals together. Useful when multiple approvers must approve the same request simultaneously.
request_id	string	Request ID	User-friendly request number (REQ0001234). Auto-generated and displayed to users instead of sys_id.
parent	reference	Parent	Rarely used in catalog context but inherited from task. Usually null for top-level catalog requests.
due_date	glide_date_time	Due date	When the entire request should be fulfilled. Calculated from SLA or manually set. Child RITMs may have different due dates.
correlation_display	string	Correlation display	Groups related requests for reporting. Often populated by integrations or bulk ordering processes.
catalog	reference	Catalog	Which service catalog this request came from. Important for multi-catalog implementations with different approval workflows.
business_service	reference	Business Service	Links request to CMDB business service for impact analysis. Usually inherited from the catalog item configuration.
reassignment_count	integer	Reassignment count	Tracks how many times the request was reassigned. Useful for identifying problematic approval chains or fulfillment bottlenecks.

Common Queries

Get all active catalog requests

var gr = new GlideRecord('sc_request');
gr.addActiveQuery();
gr.query();

while (gr.next()) {
    // Active means state != 3 (closed complete) and state != 4 (closed incomplete)
    gs.info('Request: ' + gr.request_id + ', State: ' + gr.state.getDisplayValue());
}

Find approved requests for a specific user awaiting fulfillment

var gr = new GlideRecord('sc_request');
gr.addQuery('state', 'approved');
gr.addQuery('requested_for', 'a8f98bb0eb32010045e1a5115206fe3a'); // specific user sys_id
gr.addQuery('stage', 'fulfillment');
gr.orderByDesc('sys_created_on');
gr.query();

while (gr.next()) {
    // These requests are approved but still being fulfilled
    gs.info('Request ' + gr.number + ' approved, total cost: $' + gr.price);
}

Get requests opened this month with their RITM count for department spending report

var gr = new GlideRecord('sc_request');
var startOfMonth = new GlideDateTime();
startOfMonth.setDayOfMonthUTC(1);
startOfMonth.setHourUTC(0);
startOfMonth.setMinuteUTC(0);
startOfMonth.setSecondUTC(0);

gr.addQuery('sys_created_on', '>=', startOfMonth);
gr.addQuery('requested_for.department', '!=', '');
gr.query();

while (gr.next()) {
    // Count child RITMs for each request
    var ritmGR = new GlideRecord('sc_req_item');
    ritmGR.addQuery('request', gr.sys_id);
    ritmGR.query();
    
    gs.info('Dept: ' + gr.requested_for.department.getDisplayValue() + 
            ', Items: ' + ritmGR.getRowCount() + ', Cost: $' + gr.price);
}

Count requests by state using GlideAggregate

var ga = new GlideAggregate('sc_request');
ga.addAggregate('COUNT');
ga.groupBy('state');
ga.query();

while (ga.next()) {
    var state = ga.state;
    var count = ga.getAggregate('COUNT');
    
    // Convert state integer to display value
    var tempGR = new GlideRecord('sc_request');
    tempGR.initialize();
    tempGR.state = state;
    
    gs.info('State: ' + tempGR.state.getDisplayValue() + ', Count: ' + count);
}

Wrong way vs right way to get request with all its items

// WRONG: Expensive join query
// var gr = new GlideRecord('sc_request');
// gr.addQuery('requested_for', userId);
// gr.addQuery('RELATEDLISTsc_req_item.state', 'approved');

// RIGHT: Query parent first, then children
var requestGR = new GlideRecord('sc_request');
requestGR.addQuery('requested_for', 'a8f98bb0eb32010045e1a5115206fe3a');
requestGR.query();

while (requestGR.next()) {
    var ritmGR = new GlideRecord('sc_req_item');
    ritmGR.addQuery('request', requestGR.sys_id);
    ritmGR.addQuery('state', 'approved');
    ritmGR.query();
    
    // Now you have both parent and filtered children efficiently
    gs.info('Request: ' + requestGR.number + ', Approved items: ' + ritmGR.getRowCount());
}

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_request