Documenting OOTB Lifecycle Behavior for Requests, RITMs, and Catalog Tasks

[Nguyen Duong1]

Hi all,

I’m currently investigating the out-of-the-box (OOTB) lifecycle behavior for Requests (REQ), Requested Items (RITM), and Catalog Tasks (SC_TASK), with a focus on how the following fields change throughout the process:

• Approval

• State

• Stage

My objectives are to:

1. Document what happens OOTB as a request progresses through its lifecycle.

2. Capture the field values (Approval, State, Stage) across REQ, RITM, and SC_TASK at each stage.

3. Understand the behavior in special scenarios such as:

   • Request/item rejection

   • Skipped or incomplete tasks

4. Identify any business rules, flows, or scripted logic that directly reference or rely on the templated Requested Item flow stages.

   • This is especially important because some OOTB business rules use hard-coded stage values to trigger or enforce behavior. If these aren’t fully understood or documented, it can create risks when customizing request flows or extending catalog functionality.

5. Map out how REQ, RITM, and SC_TASK records actually move between states/stages:

   • Whether transitions occur manually (via UI actions like Approve/Reject/Close)

   • Or automatically (via flows, approvals, or system events)
     Capturing this distinction is important to understand which transitions can be influenced by end users, and which are controlled programmatically.

For example, a typical catalog request might flow like this OOTB:

REQ (Request) → RITM (Requested Item) → SC_TASK(s) (Catalog Task(s))

• The REQ tracks the overall request status, for single RITM requests this is often just automatically approved.

• Each RITM progresses through its own lifecycle (e.g., Pending Approval → Approved -> Fulfillment → Closed Completed).

• SC_TASKs are generated under each RITM, and their completion (or rejection/skipping) drives the RITM and eventually the REQ forward.

• Depending on what happens in each subsequent level down, the parent records are automatically updated as well. This behaviour happens OOB when using the OOB stages but isn't well documented.

Question:
Has anyone already documented or come across official resources that capture this OOTB behavior? Additionally, are there specific business rules, flows, or scripts tied to these default lifecycle stages and transitions (manual or automated) that I should be aware of when documenting this?

[prerna_sh]

Hi @Nguyen Duong1 

You may find these articles useful:
Service Catalog and Workflow Overview - Support and Troubleshooting
When catalog task closes what is the order of out-of-the-box bus.rules that execute on requested ite...
Solved: OOTB flow for Catalog Items - ServiceNow Community
Service Catalog Item Request and Service Catalog Request OOB workflows are missing - Support and Tro...
Please let me know, if anything else is required.


If my response solves your query, please marked helpful by selecting Accept as Solution and Helpful. Let me know if anything else is required.
Thanks,
Prerna

[Shashank_Jain]

@Nguyen Duong1 , 

I guess there is no good document online there mentioning the complete workflows and scripts used in the request management process.

As per my suggestion, it would be easy if you picked a PDI and did research on your own basis and tried to create a doc. It will not take much time...................

PS : You will get the theoretical part, like how the lifecycle process works and how the flows work from a general view, but finding flows and scripts online will be tough in some places.

I would suggest you sit back and create an easy understable doc instead of wasting your good time and energy on searching online for those.

Hope it helps!

[Nguyen Duong1]

Yea i figured as much, I'm already going through the PDI and checking on my own, it isn't quick though so i was hoping someone already had it to save some time, but doesn't seem like it.

[Shashank_Jain]

@Nguyen Duong1 ,

If I got some time, I will surely create one mentioning the OOB flows , scripts and notifications for request management.

It will be helpful for others tooo!