RITM

What It Is

A RITM (Requested Item) is the atomic unit of work within ServiceNow's Service Catalog system, representing one specific item ordered within a broader request. When a user submits a service catalog request for multiple items — say, a laptop, software licenses, and building access — each ordered item becomes its own sc_req_item record. This differs from general IT terminology where "requested item" might simply mean "something someone asked for" — in ServiceNow, it's a specific record type with defined states, workflows, and relationships that governs how individual catalog orders get fulfilled.

Architecturally, RITMs sit at the critical junction between user intent and operational execution within ServiceNow's Service Management suite. They inherit context from their parent sc_request record while spawning child sc_task records that represent the actual work steps. This three-tier hierarchy enables ServiceNow to separate the concerns of request intake, item-level approval and tracking, and granular task execution. Without this middle layer, you'd either lose the ability to manage individual items within multi-item requests, or you'd have to build complex task relationships that recreate what RITMs already provide.

From a business operations perspective, RITMs solve the fundamental problem of tracking and fulfilling discrete service requests within larger orders while maintaining visibility and control. In practice, different catalog items require different approval chains, fulfillment teams, and SLAs — even when ordered together. A laptop might need manager approval and IT provisioning, while software access might need security review and automated provisioning. RITMs allow each item to follow its own lifecycle independently while rolling up status to the parent request for user visibility.

ServiceNow designed this multi-layered approach because early ITSM tools typically treated each catalog submission as a monolithic work item, creating operational nightmares when users ordered multiple items with different fulfillment requirements. The alternative would be forcing users to submit separate requests for each item, which creates poor user experience and fragments related requests. Some organizations using other ITSM platforms still live with this compromise today. ServiceNow's RITM concept allows natural user ordering behavior while providing the operational granularity that fulfillment teams actually need.

Different personas interact with RITMs in fundamentally different ways, and understanding these interaction patterns is crucial for platform success. End users primarily see RITMs through the Service Portal as line items within their requests, caring mainly about status and delivery timelines. Fulfillment teams work directly with RITM records, updating them as work progresses and using them to coordinate with other teams. Admins configure RITM workflows, approval processes, and state transitions, while developers often script against RITMs to automate status updates, integrate with external systems, or generate related records. Process owners rely on RITM reporting to understand service delivery performance and identify bottlenecks.

Without RITMs, ServiceNow's Service Catalog would collapse into either an unusable monolith or a fragmented collection of disconnected requests. You'd lose the ability to show users a unified view of multi-item requests while maintaining operational granularity. Approval workflows would become impossibly complex, trying to handle multiple items with different requirements within a single process. Reporting would be crude, unable to distinguish between request volume and item volume, or track fulfillment performance at the appropriate level of detail. The entire concept of service delivery management within ServiceNow depends on RITMs providing this crucial middle layer of granularity and control.

Where It Fits in the Platform

RITMs occupy the middle tier of ServiceNow's Service Management hierarchy, inheriting from the task table like incidents and changes, but serving the specific function of catalog fulfillment. They extend the base task functionality with catalog-specific fields like item details, variables, and pricing information. This inheritance means RITMs automatically participate in ServiceNow's broader task management ecosystem — SLAs, assignment rules, notifications, and approval workflows all work naturally with RITMs because they're built on the same foundation as other work records.

The RITM sits at the convergence of multiple ServiceNow applications and processes. It connects Service Catalog ordering with ITSM work management, often triggering incident or change records for complex fulfillments. For asset-related requests, RITMs interface with ITAM processes, automatically creating or updating configuration items. In organizations with ITOM, RITMs might trigger Discovery scans or orchestrate provisioning workflows. This positioning makes RITMs one of the most integrated record types in the platform — they rarely exist in isolation but instead serve as orchestration points for cross-application processes.

Key Relationships:

• Service Catalog Request (sc_request) — RITMs belong to exactly one request through the request reference field. The request provides user context, overall status, and serves as the user-facing container for multiple items.
• Catalog Item (sc_cat_item) — Each RITM references the catalog item it was created from through cat_item, inheriting workflows, approval processes, and fulfillment templates.
• Catalog Tasks (sc_task) — RITMs spawn one or more tasks that represent the actual work steps. Tasks reference their parent RITM through request_item and automatically update RITM state as they complete.
• Variable Answers — User responses to catalog item questions are stored in separate tables (sc_item_option, sc_item_option_mtom) but linked to the RITM, providing the context needed for fulfillment.
• Configuration Items — For hardware or software requests, RITMs often create or update CIs through the configuration_item reference field, linking the request to the delivered asset.
• Approvals — Complex approval processes often operate at the RITM level rather than the request level, since different items may require different approvers based on cost, risk, or business rules.

How You Encounter This in Practice

Debugging Why Multi-Item Requests Get Stuck

You're a ServiceNow admin and users are complaining that their service requests show as "In Progress" for weeks, even though some items have been delivered. When you investigate the sc_request record, you see it's waiting for all items to complete, but drilling into the related sc_req_item records reveals that one RITM is stuck in "Pending Approval" while others show "Closed Complete." Understanding RITMs immediately clarifies that the parent request state depends on individual item states, and you need to resolve the stuck approval at the RITM level, not manipulate the request directly. Without this understanding, admins often try to manually close the request or reset its state, breaking the referential integrity and creating data inconsistencies that cascade through reporting.

Building Reports That Actually Reflect Service Delivery

You're a process owner tasked with reporting on service catalog performance, and your initial reports based on sc_request records show misleading metrics — request volumes seem low, but fulfillment teams claim they're overwhelmed. When you discover that each request can contain multiple RITMs, and that SLA performance should be measured at the RITM level since that's where actual work happens, your reporting strategy fundamentally changes. Understanding RITMs reveals that meaningful service delivery metrics — fulfillment time, approval bottlenecks, team workload — all operate at the item level, not the request level. Teams trying to report on request-level data miss the granularity needed for operational improvement and often make wrong conclusions about capacity and performance.

Integrating External Systems with Catalog Fulfillment

You're a developer building an integration between ServiceNow and your organization's asset management system, and initially you assume you should trigger provisioning workflows from sc_request records. But when you test with multi-item orders, you realize the external system needs individual item details, quantities, and configurations that only exist at the RITM level. Understanding that RITMs contain the specific catalog item reference, user variable responses, and approval status needed for provisioning completely reshapes your integration architecture. Without this knowledge, developers often build overly complex request parsing logic or miss critical item-specific data, leading to failed provisioning attempts and poor error handling when individual items within a request fail.

What People Get Wrong

This fundamental misunderstanding drives some of the most persistent problems in ServiceNow catalog implementations. While both sc_request and sc_req_item inherit from the task table and share some common fields, they serve completely different functions and have different lifecycles. Requests are containers that group related items and provide user-facing status, while RITMs are the operational units where actual work happens. This misconception exists because both appear in similar lists, both have states and assignments, and both can have approvals — but the similarities are surface-level.

In production, this mistake manifests when admins try to assign entire requests to fulfillment groups instead of individual RITMs, creating confusion about which team handles which items. It appears when developers write business rules that trigger on request state changes, missing the granular RITM state changes where the real action happens. Most critically, it surfaces in approval processes where admins try to approve multi-item requests at the request level, not realizing that different items need different approvers or that partial approvals should be possible.

The consequences cascade through the entire catalog system. Users lose visibility into individual item progress, seeing only generic request-level status that doesn't help them understand what's actually happening. Fulfillment teams can't properly coordinate work because assignments and notifications operate at the wrong level. Reporting becomes meaningless because metrics aggregate at the request level while operational reality happens at the item level. Organizations that don't grasp this distinction end up with catalog processes that technically function but provide poor user experience and limited operational control.

RITM state management is deeply integrated with ServiceNow's workflow engine, approval processes, and task creation logic — but this integration is often invisible to administrators who see only the simple state field on the form. When RITMs move between states like "Pending Approval," "Work in Progress," and "Closed Complete," they're not just updating a display value — they're triggering business rules that create tasks, send notifications, update parent request states, and potentially create or modify related records. This misconception develops because RITM states look like simple choice fields, and ServiceNow allows manual state changes in many contexts.

Admins who manually manipulate RITM states to "fix" stuck requests often break automated processes in subtle ways that don't immediately surface. Moving a RITM from "Pending Approval" to "Work in Progress" without completing the approval bypasses security controls and audit trails. Changing a RITM to "Closed Complete" without letting tasks finish naturally can leave orphaned sc_task records that continue generating notifications or prevent proper cleanup processes from running. Most dangerously, manual state manipulation can prevent SLA calculations from working correctly, making performance reporting unreliable.

The impact compounds over time as organizations lose trust in their catalog processes and begin building manual workarounds for problems that stem from broken state management. Users stop relying on request status because it becomes unreliable. Fulfillment teams develop shadow processes because automated task creation becomes unpredictable. Management loses confidence in service delivery metrics because the underlying data integrity has been compromised by well-intentioned but incorrect manual interventions.

Admin vs Developer Perspective

For Admins

Admins primarily focus on RITM workflows, assignment rules, and approval processes that determine how requested items move through fulfillment. They configure the state transitions and business rules that automatically progress RITMs from Open to Work in Progress to Closed Complete. The critical admin decision is whether to use RITMs for simple approval-only items or create child sc_task records for complex multi-step fulfillment. Admins also manage RITM reporting and ensure proper SLA attachments since RITMs inherit SLAs from their parent Request differently than child tasks do.

For Developers

Developers script heavily against the sc_req_item table for custom fulfillment automation, variable processing, and integration with external systems. The key scripting pattern involves querying RITMs by their request field to find related items, then accessing catalog variables through ritm.variables or the Variables API. Developers frequently build business rules that automatically create sc_task records from RITM data, populate CMDB records during fulfillment, or integrate with REST APIs to provision external resources based on RITM variable values.

How It Connects to Other Concepts

• Service Catalog Request — the parent record that contains one or more RITMs, linked via the request reference field. When a Request is cancelled or modified, all child RITMs are affected, and the Request's overall state depends on the states of its RITMs.
• Service Catalog Item — the template that defines what gets created when a RITM is generated, referenced through the cat_item field. The catalog item's workflow, variables, and fulfillment configuration directly control how the RITM behaves during its lifecycle.
• Catalog Tasks (sc_task) — child records created from RITMs to handle complex multi-step fulfillment processes. Tasks inherit many fields from their parent RITM but can be assigned to different groups and have independent workflows, allowing parallel or sequential processing of fulfillment steps.
• Catalog Variables — the dynamic form data captured during catalog item ordering, accessible on RITMs through the Variables API or dot notation. Variable values drive fulfillment logic, populate downstream systems, and determine which workflows or tasks get created from the RITM.
• Workflows and Business Rules — automation that triggers when RITMs are created, updated, or change state. Workflows handle approval routing and complex fulfillment orchestration, while business rules perform immediate actions like creating tasks, updating CMDB records, or calling external APIs based on RITM data.
• SLAs and Metrics — time-based commitments that attach to RITMs based on catalog item configuration, requester attributes, or fulfillment group assignment. SLA definitions on RITMs often differ from those on child tasks, creating complex scenarios where parent and child records have different breach calculations and escalation paths.

Junior vs Senior Knowledge Gap

Juniors typically think of RITMs as simple containers that automatically handle catalog item fulfillment, missing the complex relationship between RITMs and their child tasks. They often create overly complicated workflow designs that try to do everything at the RITM level instead of understanding when to push work down to sc_task records for parallel processing. The most common mistake is assuming that closing a RITM automatically handles all the business logic needed for fulfillment, when in reality the RITM state changes should be driven by completion of underlying work, not the other way around.

The mental model shift happens when professionals understand that RITMs are coordination points, not work containers. Experienced developers know that the real fulfillment logic lives in business rules, workflows, and external integrations that react to RITM state changes, while the RITM itself serves primarily as a data aggregation point and progress tracker. They design RITM processes thinking about error handling, rollback scenarios, and partial fulfillment states that juniors never consider until something breaks in production.

Senior professionals understand the subtle performance implications of RITM queries and variable access patterns. They know that accessing catalog variables through the Variables API creates additional database queries, so they cache variable values in custom fields when building high-volume automation. They also understand how RITM inheritance affects child task behavior, particularly around assignment groups, SLA definitions, and approval requirements that can create confusing fulfillment scenarios when not properly designed.

The questions an experienced architect asks reveal the depth: How will this RITM design handle partial fulfillment when some tasks succeed and others fail? What happens to child tasks when the parent RITM gets cancelled after work has already started? How will we track fulfillment progress when multiple external systems are involved, and some don't provide real-time status updates? These scenarios only surface after managing complex service catalogs at scale, where the simple happy-path fulfillment that dominates documentation proves inadequate for real business processes.

Quick Reference

• RITMs automatically inherit the assignment_group from their catalog item configuration, but this can be overridden by workflow or business rule logic during creation.
• The stage field on RITMs tracks workflow progress independently of the state field, allowing for detailed progress reporting even within the same state.
• Catalog variable values accessed through ritm.variables.variable_name create additional GlideRecord queries to the sc_item_option_mtom table, which can impact performance in bulk operations.
• RITMs created from catalog items with the No cart option still create a parent Request record, just with a single RITM child.
• The correlation_id field links RITMs to external system records and is commonly used for tracking provisioning status from third-party APIs.
• Business rules on sc_req_item run before child sc_task creation, allowing RITM data to influence task generation logic and inheritance.
• RITMs cannot be manually created through the standard interface — they must be generated through catalog item ordering or REST API calls that mimic the ordering process.
• The price field on RITMs can be dynamically calculated based on catalog variables, but changes to the price after RITM creation don't automatically update the parent Request's total.
• RITMs in Closed Incomplete state can be reopened and moved back to Open, but Closed Complete RITMs require custom scripting to reopen properly.
• When a RITM's parent Request is cancelled, the RITM automatically moves to Request Cancelled state, but any running workflows continue unless explicitly terminated by business rule logic.