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?

[Shashank_Jain]

@Nguyen Duong1 ,

Are you done with the document creation for this?