sc_req_item Table — ServiceNow Reference

Table Reference/sc_req_item

The sc_req_item table stores individual catalog items (RITMs) ordered within Service Catalog requests. Owned by the Service Catalog module and extends the task table. Most fulfillment workflows, catalog Business Rules, and approval processes script against this table rather than the parent sc_request.

What This Table Is

The sc_req_item table stores individual catalog items (RITMs) that users order through the Service Catalog. When someone submits a cart with three items, ServiceNow creates one sc_request record and three sc_req_item records. Each RITM represents one fulfillment unit with its own approval chain, assignment, and lifecycle.

Owned by the Service Catalog module, this table drives the entire catalog fulfillment process from order to delivery. RITMs flow through states like Pending Approval, Work in Progress, and Closed Complete. The state field controls workflow progression, while stage tracks high-level phases like Request Approved or Fulfillment.

The table extends task, inheriting fields like assigned_to, priority, and work_notes. No child tables extend sc_req_item in baseline ServiceNow, though custom implementations sometimes create subtables for specialized catalog items like hardware requests or access requests.

Large enterprises typically see 50,000-500,000 RITM records annually, with peaks during hardware refresh cycles or new hire onboarding. The table performs well at scale, but complex queries joining sc_item_option_mtom for variable values can slow down significantly beyond 100,000 records without proper indexing.

When You'll Script Against This Table

You'll script against sc_req_item most often in catalog Business Rules (especially before/after insert and update), fulfillment Flow Designer actions, and Workflow activities. Script Includes that handle catalog automation, approval engines, and integration with external provisioning systems constantly query this table. Scheduled Jobs that monitor SLA breaches or send fulfillment reminders also run against RITM records.

The catalog_admin role provides full access, while catalog role allows reading most fields but restricts updates to assigned fulfillment groups. Record-level ACLs limit users to seeing their own requests unless they're in the fulfillment chain.

Common scripting patterns:

Auto-assign RITMs to fulfillment groups based on cat_item or requester's location
Extract variable values from sc_item_option_mtom for provisioning systems
Update state to Work in Progress when external system accepts the request
Create tasks, change requests, or project records as fulfillment work
Calculate SLA due dates based on cat_item.delivery_time and business calendars
Send notifications to requesters when state changes to Closed Complete
Generate configuration items when hardware or software gets provisioned

Table Gotchas

⚠️

The state field uses integer values, not string choices. 'Pending Approval' is -5, 'Work in Progress' is 1, 'Closed Complete' is 3. Always query by number: current.state == 1, never current.state == 'Work in Progress'.

⚠️

Variable values aren't stored on the RITM record itself. They're in sc_item_option_mtom as many-to-many relationships. Use getRITMVariableValue() or query the mtom table directly - never assume variables are direct RITM fields.

The opened_by field points to who submitted the request, while request.requested_for is the actual recipient - crucial for manager approval logic
Changing state automatically updates stage via Business Rules - don't manually set both or you'll get conflicts

⚠️

Queries joining sc_item_option_mtom can timeout on large datasets. The mtom table lacks indexes on item_option_new. Always filter RITMs first, then get variables for the smaller result set.

The approval field shows overall approval status, but individual approvals live in sysapproval_approver - check both for complete approval logic
ACLs prevent users from seeing RITMs they didn't request unless they're assigned or have fulfillment roles - test your scripts with non-admin users

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.

As an extension of task, RITMs inherit all task functionality including assignments, work notes, and SLA tracking. The parent sc_request holds cart-level information like the original requester and submission timestamp. Most fulfillment logic operates on individual RITMs, not the parent request.

The sc_item_option_mtom table stores all variable values submitted with the RITM - you'll join this constantly to get user selections. sc_cat_item defines the catalog item being requested and contains fulfillment rules, delivery times, and approval mappings. The sysapproval_approver table tracks individual approvals when RITMs require manager or department head sign-off.

Fulfillment workflows often create records in sc_task for manual work items, change_request for infrastructure changes, or cmdb_ci when provisioning creates new assets. These relationships typically use the task_relations table or direct reference fields back to the originating RITM.

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	choice	State	Current workflow state using integer values: -5 (Pending Approval), 1 (Work in Progress), 3 (Closed Complete). Query by number, never by display value.
stage	choice	Stage	High-level fulfillment phase like 'Request Approved' or 'Fulfillment'. Auto-updated by Business Rules when state changes - don't set manually.
request	reference	Request	References the parent sc_request record. Use request.requested_for to get the actual recipient, not opened_by who might be an admin or delegate.
cat_item	reference	Catalog Item	References sc_cat_item defining what was ordered. Contains fulfillment rules, approval mappings, and delivery SLAs used by automation.
quantity	integer	Quantity	Number of items requested. Used for cost calculations and inventory management. Defaults to 1 but can be set by catalog item configuration.
price	decimal	Price	Total cost for this RITM (quantity × unit price). Calculated from cat_item.cost unless overridden by variable-driven pricing rules.
recurring_price	decimal	Recurring Price	Monthly or periodic cost for subscription items. Used by financial management for ongoing cost allocation and budgeting.
approval	choice	Approval	Overall approval status: not requested, pending, approved, rejected. Check sysapproval_approver for individual approver details and logic.
delivery_address	string	Delivery Address	Physical delivery location for hardware items. Often populated from user's location record but can be overridden by delivery variables.
estimated_delivery	glide_date_time	Estimated Delivery	Expected completion date calculated from cat_item.delivery_time and business calendar. Updated by fulfillment workflows as work progresses.
received	glide_date_time	Received	When the requester confirmed receipt of the item or service. Populated by notifications or self-service portals, triggers final closure.
backordered	glide_date_time	Backordered	Set when item is out of stock or delayed. Triggers notifications to requesters and updates delivery estimates in fulfillment dashboards.
context	reference	Context	Links to the sc_request parent. Redundant with request field but used by some OOB workflows - maintain consistency between both fields.
configuration_item	reference	Configuration Item	References cmdb_ci when fulfillment creates or modifies a configuration item. Used for asset tracking and service mapping integration.
opened_by	reference	Opened By	Who submitted the request - may be admin or delegate. For actual recipient, use request.requested_for. Critical distinction for approval and notification logic.
variables	variables	Variables	Virtual field for accessing catalog variables. Don't query this directly - use sc_item_option_mtom table or getRITMVariableValue() API instead.

Common Queries

Get all active requested items

// Most basic query - active RITMs across all states
var gr = new GlideRecord('sc_req_item');
gr.addQuery('active', true);
gr.orderBy('number');
gr.query();
while (gr.next()) {
    gs.info('RITM: ' + gr.number + ', State: ' + gr.state.getDisplayValue());
}

Find RITMs pending approval for a specific catalog item

// Common approval dashboard query
var gr = new GlideRecord('sc_req_item');
gr.addQuery('state', -5); // Pending Approval - use number not string
gr.addQuery('cat_item.name', 'Standard Laptop');
gr.addQuery('active', true);
gr.orderBy('sys_created_on');
gr.query();
while (gr.next()) {
    gs.info('RITM ' + gr.number + ' waiting approval since ' + gr.sys_created_on);
}

Get overdue RITMs assigned to current user's group

// Real-world fulfillment workload query
var gr = new GlideRecord('sc_req_item');
gr.addQuery('assignment_group', gs.getUser().getMyGroups().toString());
gr.addQuery('state', '1'); // Work in Progress
gr.addQuery('estimated_delivery', '<', new GlideDateTime());
gr.addQuery('active', true);
gr.orderBy('estimated_delivery');
gr.query();
while (gr.next()) {
    gs.info('Overdue: ' + gr.number + ', Due: ' + gr.estimated_delivery);
}

Count RITMs by state for reporting dashboard

// Aggregate query for fulfillment metrics
var ga = new GlideAggregate('sc_req_item');
ga.addQuery('active', true);
ga.addQuery('sys_created_on', '>=', 'javascript:gs.daysAgoStart(30)');
ga.addAggregate('COUNT');
ga.groupBy('state');
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 get variable values

// WRONG: variables aren't direct RITM fields
// var badValue = ritm.variables.laptop_model; // This fails!

// RIGHT: Use the many-to-many relationship
var gr = new GlideRecord('sc_item_option_mtom');
gr.addQuery('request_item', ritmSysId);
gr.addQuery('sc_item_option.item_option_new.name', 'laptop_model');
gr.query();
if (gr.next()) {
    var laptopModel = gr.sc_item_option.value;
    gs.info('Selected 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_req_item