---
sourceDocument: Brazil IT Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/it-service-management

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil IT Service Management

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# Request Management architecture

# Request Management architecture {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Request Management architecture

Request Management in ServiceNow defines the data model and process flow for handling catalog item requests, starting from cart creation to fulfillment.
It is triggered only when a catalog item from theCatalog Item \[sccatitem\]table is requested.
The process generates records following a specific hierarchy, with variables associated exclusively to theRequested Item \[screqitem\]table.
Show full answer Show less  

## Request Management hierarchy and constraints

* Service Catalog initiates the request process.
* Variables are supported only on the Requested Item table, not on extended tables.
* Record producers should not be used to create or insert records directly into the Request \[screquest\], Request Item \[screqitem\], or Catalog Task \[sctask\] tables or their extensions.
* Business rules with *before* triggers should be avoided on Request, Request Item, Cart \[sccart\], and Cart Item \[sccartitem\] tables.

## Request management process

The process varies slightly depending on how the catalog item is ordered:

* **Ordering a catalog item directly (without a cart):**
  * A temporary cart (**sccart**) is created.
  * The catalog item and user-input variables are added as a record in **Cart Item \[sccartitem\]**.
  * Variables are saved in the **Options \[scitemoption\]** and **Variable Ownership \[scitemoptionmtom\]** tables.
  * Checkout initializes but does not immediately commit records in **Request \[screquest\]** and **Request Item \[screqitem\]** tables.
  * The Request Item record references the Request record, and variables are updated accordingly.
  * Finally, both Request and Request Item records are committed to the database.
* **Ordering after adding items to the cart and checking out:**
  * The default cart is checked out.
  * The steps for direct ordering apply to each catalog item in the cart sequentially.
* **Ordering using an order guide:**
  * For a two-step checkout, a temporary cart is used for all items.
  * For a three-step checkout, the default cart is used.
  * The same process steps as direct ordering apply.

## Practical considerations for ServiceNow customers

* Understand the strict data model hierarchy and avoid creating or manipulating request management records outside of supported methods to ensure data integrity.
* Variables should only be associated with Requested Items, which is important for customizing request forms and workflows.
* When customizing workflows or business rules, avoid *before* triggers on key request management tables to prevent unexpected behavior.
* Be aware that the base system workflow attached to requests is demo data and should be adapted or replaced for production use.  
Request Management defines the data model and processing flow for catalog item requests, from cart creation through record
fulfillment.

## Request Management hierarchy {#request-management-architecture__section_ctw_bbb_sgb}

Service Catalog is the starting point of the request management process. The request
management process is triggered only when a catalog item from the Catalog Item \[sc_cat_item\]
table is requested.

When a user submits a request for a catalog item, records are generated in the following
hierarchy.  
Note:  
Variables are associated only with the Requested Item \[sc_req_item\] table. Variables are not supported for extended tables.  
Figure 1. Request Management hierarchy  
Note:  
When you configure Request Management:

* The data model does not support a record producer generating request management objects such as request, request item, and catalog task. Therefore, do not use a record producer to insert records in the following request management tables or their extensions:
  * Request \[sc_request\]
  * Request Item \[sc_req_item\]
  * Catalog Task \[sc_task\]
  {#request-management-architecture__ul_rfm_wdb_sgb}
* Do not write business rules with the `before` trigger for the following tables:
  * Request \[sc_request\]
  * Request Item \[sc_req_item\]
  * Cart \[sc_cart\]
  * Cart Item \[sc_cart_item\]
  {#request-management-architecture__ul_mmy_pdb_sgb}
{#request-management-architecture__ul_jg2_pdb_sgb}

## Request management process {#request-management-architecture__section_wxz_tcb_sgb}

Catalog item is ordered directly without adding it to the cart{#request-management-architecture__cat-item-direct}
:   When a catalog item is ordered or requested directly without adding it to the cart, the
    following steps are performed:

    1. A temporary cart, sc_cart, is created.
    2. The catalog item along with the variables (values entered by the user) is added to the temporary cart as a record in the Cart Item \[sc_cart_item\] table.
    3. The variables are saved in the Options \[sc_item_option\] and Variable Ownership \[sc_item_option_mtom\] tables.
    4. The temporary cart is checked out by performing these steps.
       1. A record in the Request \[sc_request\] table is initialized but not committed in the database.
       2. A record in Request Item \[sc_req_item\] table is initialized but not committed in the database.
       3. The request reference for the Request Item \[sc_req_item\] table record is updated with the Request \[sc_request\] table record.
       4. The variables record in the Options \[sc_item_option\] and Variable Ownership \[sc_item_option_mtom\] tables are updated based on the Request Item \[sc_req_item\] table record.
       5. The Request Item \[sc_req_item\] table record is committed in the database.
       6. The Request \[sc_request\] table record is committed in the database.
       {#request-management-architecture__ol_dt4_2db_sgb}
    {#request-management-architecture__ol_n3k_zcb_sgb}

Request is submitted after adding the item to the cart

:   If a catalog item is added to the cart and the request is submitted using the checkout process, the default cart is checked out. All steps mentioned in the preceding scenario, Catalog item is ordered directly without
    adding it to the cart, are applicable. However, if multiple catalog items are added to the cart, step 2 through step 4 of the checkout process are
    repeated for each item.

Request is submitted using an order guide

:   For a two-step order guide checkout, the temporary cart is used for all items. For a three-step order guide checkout, the default cart is used for the items.All steps mentioned
    in the preceding scenario, Catalog item is ordered directly without adding it to the cart,
    are applicable.

Note:  
The base system workflow attached to the request is demo data.
**Related tasks**   

* [Create a catalog request in Agent Workspace](https://www.servicenow.com/docs/sJiALTPI32_eMTmiqNfdAQ "You can create a catalog request in Agent Workspace to join the Service Catalog flow from a different flow. For example, from an incident flow, you can create a request, and associate the request with the incident. It helps you in tracking the requests associated with an incident and vice versa.")
* [Create a request from Universal Request](https://www.servicenow.com/docs/tSqm3jo_WOXn~U7DS1bUnQ "As a routing agent, create a request from a universal request and then assign it to the appropriate assignment group. The request manager handles the requested items and takes further actions to fulfill the request.")