Request

What It Is

A Request in ServiceNow is the parent record stored in the sc_request table that represents a single catalog submission by an end user. Unlike the generic IT concept of a "request" which might mean any ask for service, ServiceNow's Request is specifically the container record created when someone submits items through the Service Catalog. Each Request contains one or more Requested Items (RITMs) — the individual catalog items being ordered — and maintains the business context, approval routing, and overall lifecycle state of that catalog transaction.

Architecturally, the Request sits at the orchestration layer of ServiceNow's ITSM framework, bridging the user-facing Service Catalog with the backend fulfillment processes. It's part of the Request Management application within the broader ITSM suite, designed to handle the complexity of multi-item orders where different catalog items might follow different approval paths, have different fulfillment teams, or require different SLA tracking. The Request provides a single point of reference for the entire catalog transaction while allowing granular control over individual items through their child RITMs.

The operational problem Request solves is the need to group related catalog purchases while maintaining independent tracking of each item. In practice, users often order multiple items in a single catalog session — a laptop, software licenses, and access permissions, for example. Without the Request container, each item would exist in isolation, making it impossible to understand the business context of the purchase, apply consistent approval logic, or provide meaningful status updates to the requestor. The Request enables ServiceNow to treat the submission as a business transaction while routing individual items through appropriate fulfillment workflows.

ServiceNow built this two-tier architecture — Request containing RITMs — because enterprise catalog management requires both transaction-level and item-level control. The alternative approach of treating each catalog item as a standalone record would lose the grouping context and make approval workflows unnecessarily complex. Some ITSM tools use a flat structure where each catalog item creates an independent ticket, but this creates problems when users expect to see their "order" as a single entity, or when approval logic needs to consider the entire purchase rather than individual components. ServiceNow's design reflects the reality that catalog requests are business transactions that happen to contain multiple fulfillable items.

End users interact with Requests primarily through the Service Portal, where they see their Request as a single submission with an overall status and the ability to track individual items within it. Catalog administrators configure Request behavior through catalog item settings, approval rules, and workflow definitions, treating the Request as the policy enforcement point for catalog transactions. Developers work with Requests when building custom catalog items, approval processes, or integrations, often needing to understand the parent-child relationship to properly query or update catalog submissions. Process owners rely on Request-level reporting to understand catalog usage patterns, approval bottlenecks, and fulfillment performance across their organization's service offerings.

Without the Request concept, ServiceNow's catalog functionality would collapse into a collection of unrelated transactions with no business context. Users would lose the ability to see their "cart" as a single order, approval processes couldn't consider the full scope of what someone is requesting, and reporting would be limited to individual item statistics rather than business transaction analysis. The Request is what makes ServiceNow's catalog behave like an enterprise procurement system rather than a simple ticketing tool, enabling the complex approval routing, bundled fulfillment, and transaction-level analytics that large organizations require.

Where It Fits in the Platform

Request sits at the center of ServiceNow's catalog ecosystem, functioning as the transaction coordinator between the user-facing Service Catalog and the backend fulfillment infrastructure. It exists in the ITSM application stack alongside Incident, Problem, and Change, but serves a fundamentally different role — orchestrating planned service delivery rather than managing unplanned disruptions or modifications. The Request's position in the data model makes it the natural integration point for approval workflows, SLA management, and fulfillment tracking across the entire catalog operation.

Within ServiceNow's broader architecture, Request represents the business transaction layer that connects catalog presentation with operational fulfillment. It inherits from the Task table like other ITSM records, giving it access to assignment, approval, and SLA capabilities, while maintaining specialized relationships with catalog-specific constructs like Variables, Catalog Items, and Order Guides. This positioning allows Request to leverage platform-wide capabilities — workflow engine, notification system, reporting framework — while maintaining the catalog-specific business logic needed for procurement-style operations.

Key Relationships:

• RITM (Requested Item): The child records that represent individual catalog items within a Request. Each Request contains one or more RITMs, with the Request managing the overall transaction while RITMs handle item-specific fulfillment workflows.
• Service Catalog: The user interface and item repository that generates Requests when users submit catalog orders. The catalog defines what can be requested, while the Request captures what was actually requested in a specific transaction.
• Variable: The user input captured when submitting catalog items, stored with specific assignment to the Request and its RITMs. Variables provide the customization data that fulfillment teams need to deliver the requested services.
• Order Guide: Catalog constructs that bundle multiple items into a single user experience, resulting in a Request with multiple child RITMs. Order Guides use the Request container to maintain the logical grouping of bundled items.
• Approval: The workflow process that can operate at both Request and RITM levels, with Request approvals typically handling business authorization while RITM approvals manage technical or operational sign-offs. Approvals can be configured to cascade from Request to RITMs or operate independently.
• Task: The base table that Request extends, providing core ITSM capabilities like assignment, state management, and SLA tracking. This relationship enables Requests to participate in standard ServiceNow workflows while maintaining catalog-specific functionality.

How You Encounter This in Practice

Building a Multi-Item Approval Process

You're a ServiceNow developer tasked with implementing approval logic for software license requests that need different approvals based on cost thresholds, but the business wants a single approval for the entire order regardless of how many different software packages are included. You discover that users can submit multiple software items in one catalog session, creating a single Request with multiple RITMs, and the existing approval workflow is running separately for each RITM, creating approval chaos. Understanding that Request is the transaction container allows you to implement Request-level approval that considers the total cost across all RITMs before routing to the appropriate business approver.

Without understanding the Request concept, you'd likely build RITM-level approvals that duplicate business logic and create multiple approval requests for what should be a single business decision, frustrating approvers and creating inconsistent approval outcomes.

Troubleshooting Catalog Performance Issues

As a ServiceNow administrator, you're investigating reports that the Service Portal is slow when users try to view their request history, especially for users who've submitted many catalog requests over time. Your initial analysis shows thousands of records in various catalog-related tables, but you can't figure out why some users experience worse performance than others. You discover that the portal is querying RITMs directly rather than starting with Requests, creating inefficient database queries that scale poorly with catalog usage. Understanding that Request is the proper entry point for catalog history allows you to optimize the query structure and implement proper indexing strategies.

Without understanding the Request-RITM hierarchy, you'd likely focus on RITM table performance tuning while missing the architectural issue that Request-based queries are more efficient and provide better user experience.

Implementing Request Fulfillment Metrics

Your IT leadership wants dashboard metrics showing average time to fulfill catalog requests, but when you build initial reports using RITM data, the numbers don't match business expectations about "request fulfillment time." Users and managers think in terms of "when I submitted my request" versus "when I got everything I asked for," but your RITM-based metrics show individual item fulfillment times that don't reflect the end-to-end user experience. You realize that Request-level metrics — from submission to when all child RITMs are complete — better represent actual business value and user satisfaction with catalog services.

Without understanding that Request represents the business transaction, you'd build metrics that optimize individual item processing but miss opportunities to improve overall catalog experience and business outcomes.

What People Get Wrong

This misconception stems from the fact that both Requests and RITMs appear in many of the same lists and reports, leading people to think they're equivalent records with different formatting. In reality, they serve fundamentally different purposes in the catalog architecture. Request represents the business transaction — the user's intent to procure services — while RITMs represent the operational units of work needed to fulfill that transaction. This distinction becomes critical when building approval processes, SLA definitions, or integration points with external systems.

The confusion often arises because single-item catalog submissions create a 1:1 relationship between Request and RITM, making them appear interchangeable in simple scenarios. However, when users submit Order Guides or multiple items in a single session, the distinction becomes obvious. A Request might be "approved" as a business decision while individual RITMs are still being processed by different fulfillment teams. Variables and pricing information flow differently between the two record types, and their lifecycle states represent different aspects of the fulfillment process.

In production, treating them as interchangeable leads to approval workflows that fire at inappropriate times, SLAs that measure the wrong activities, and user communications that provide confusing status updates. For example, closing a Request when individual RITMs are still being fulfilled breaks the user experience, while routing business approvals through RITM workflows can create unnecessary complexity and approval duplication when users order multiple items.

While ServiceNow does provide some automatic state synchronization between Requests and their child RITMs, relying entirely on this automation creates gaps in request lifecycle management that become apparent in complex catalog implementations. The default behavior handles simple scenarios — like moving a Request to "Closed Complete" when all RITMs are fulfilled — but doesn't account for business rules around partial fulfillment, cancellations, or approval dependencies that many enterprises require.

This misconception develops because the out-of-box state management works adequately for basic catalog scenarios, leading administrators to assume it will scale to their organization's specific requirements. In practice, most enterprises need custom logic to handle scenarios like business approval rejection (which should close the entire Request regardless of RITM states), partial order fulfillment (where some items are delivered while others are cancelled), or priority escalation (where Request-level urgency needs to cascade to child RITMs based on business rules).

The consequence of this assumption is catalog implementations that work fine in development but break down under real-world usage patterns. Users receive incomplete status notifications, fulfillment teams work on items that should have been cancelled, and reporting shows inconsistent request states that don't reflect actual business outcomes. The fix requires implementing explicit Request state management through business rules and workflows that account for the specific lifecycle requirements of each organization's catalog processes.

Admin vs Developer Perspective

For Admins

Admins focus on catalog item configuration, approval workflows, and fulfillment groups for requests. They configure the requested_for field behavior, set up catalog variables that flow down to RITMs, and design approval processes using the sysapproval_approver table. They need to understand how request states cascade to child RITMs and when to use request-level vs item-level approvals. The key decision is whether to handle complex requirements at the request level or push logic down to individual requested items, which affects reporting and user experience.

For Developers

Developers script against requests using the Catalog Item API and the sc_request table for automation and integrations. They commonly query requests to aggregate RITM data, build custom approval engines using current.getRequestItems(), and create business rules that fire on request state changes. The GlideServiceCatalogAPI provides methods for programmatically creating requests, while the REST API enables external systems to submit and track requests. Developers must handle the parent-child relationship carefully in workflows since request completion depends on all child RITM states.

How It Connects to Other Concepts

• Requested Item (RITM) — Child records that contain the actual fulfillment work and track individual catalog item progress. Each request spawns one or more RITMs based on catalog items selected, and the request cannot close until all child RITMs reach a closed state. Variables from the request form flow down to RITMs through the variable ownership hierarchy.
• Service Catalog — The interface where users initiate requests by selecting catalog items and filling out order guides. Catalog configuration determines request numbering, approval workflows, and which fields appear on the request form. The catalog's category structure and entitlement rules control which items users can request and how those selections create the request hierarchy.
• Approval Records — Generated automatically when requests trigger approval workflows, creating sysapproval_approver records that reference the request. Request-level approvals block all child RITMs until approved, while item-level approvals only affect specific requested items. The approval engine evaluates request variables and user attributes to determine approval routing and can create parallel or sequential approval chains.
• Variables and Variable Sets — Store user input from catalog forms as sc_item_option records linked to the request. Request-level variables affect multiple catalog items in the same order, while item-specific variables only impact individual RITMs. Variable values drive approval conditions, fulfillment logic, and integrations with external systems through workflow activities and business rules.
• My Requests Portal — Displays request status, approval progress, and fulfillment updates to end users through the service portal. The portal aggregates request and RITM information to show unified status, handles request cancellations, and provides access to related records like approvals and catalog tasks. Users can track request progress, view variable values, and interact with fulfillment teams through portal comments and attachments.
• Workflow and Flow Designer — Automate request processing through approval routing, fulfillment orchestration, and integration activities. Request workflows typically handle high-level orchestration and approvals, while RITM workflows focus on item-specific fulfillment tasks. Flow Designer's Service Catalog spoke provides triggers for request events and actions for manipulating request data, approvals, and state transitions.

Junior vs Senior Knowledge Gap

Junior developers often treat requests as simple containers and don't understand the critical parent-child state dependency with RITMs. They'll close requests manually or through scripts without ensuring all child items are properly resolved, breaking the state management logic and confusing end users. They typically focus on individual catalog items rather than understanding how request-level configuration affects the entire order, leading to duplicated logic and inconsistent user experiences across related items in the same request.

The mental model shift happens when you realize that requests are orchestration records, not fulfillment records. Experienced architects design catalog items with the request context in mind, understanding that variables and approvals cascade through the hierarchy and that request-level decisions affect reporting, SLAs, and user communications. They know to configure approval workflows at the appropriate level—using request approvals for high-level authorization and RITM approvals for technical or item-specific decisions. They also understand that request state changes trigger downstream automation, so they design robust business rules that handle edge cases like partial cancellations and mixed approval outcomes.

Senior professionals know that request performance issues often stem from variable queries and approval processing, not the request records themselves. They understand the nuances of the requested_for versus opened_by relationship and how it affects notifications, approvals, and security. They know that catalog client scripts can manipulate request-level data before submission, and they've learned to handle complex scenarios like request amendments, bulk approvals, and integration failures gracefully. They also understand the limitations of the platform's request model—when to stay within the standard framework versus when to build custom solutions for complex procurement or service delivery processes.

Experienced architects ask questions that juniors don't consider: How will this request design scale when users submit orders with 50+ items? What happens to approvals when the requested-for user is inactive? How do we handle request data in reports when RITMs span multiple fulfillment groups? They understand that request design decisions made early in implementation are extremely difficult to change later because they affect historical data, established workflows, and user expectations across the entire service catalog ecosystem.

Quick Reference

• The sc_request table extends task but uses a completely different state model than incidents or changes, with states like requested, in_process, and closed_complete
• Request numbers follow the REQ prefix by default, but this can be customized per catalog or globally through the number maintenance system
• The getRequestItems() method returns a GlideRecord query on the sc_req_item table, not an array, so you must iterate through it with .next()
• Request-level approvals create sysapproval_approver records with source_table=sc_request, while RITM approvals use source_table=sc_req_item
• Variables submitted through catalog forms are stored in sc_item_option records that can reference either the request or individual RITMs depending on variable configuration
• The request_state field automatically transitions based on child RITM states, but can be manually overridden through workflow or business rules
• Portal users see request details through the sp_requests widget, which aggregates data from requests, RITMs, and approvals into a unified view
• The delivery_plan field links requests to delivery plans for tracking complex fulfillment processes across multiple teams and systems
• Deleting a request automatically deletes all child RITMs and their associated records, including variables, approvals, and catalog tasks—there's no cascade protection
• Business rules on the request table fire for every RITM state change that affects the parent request, potentially causing performance issues with large orders