include new stages to OOB step based request fulfillment flow

[Saranya S2]

Hi All, the OOB Service Fulfillment Steps base flow subflow has stages defined as Service fulfillment process, Completed and Closed Incomplete. it is a read-only flow and operates as a generic engine. it iterates through the sc_service_fulfillment_stage and sc_service_fulfillment_step tables using a loop that doesn't distinguish between step types. Is there any way we can differentiate between approvals and task and add stages as waiting for approval/approval/workinprogress? I agree we cant make any changes over there, but is there a possibility to take copy and accommodate the requested change.

[Nayan ArchX]

If it is a classic workflow, you can check out the flow,

- Add the approval step on a flow

( If you have any condition add if condition )

- Connect the flow as per your process 

- Check in the flow

[KingC]

Solution: Custom Stages in Service Fulfillment Flow
Yes — you cannot edit the OOB "Service Fulfillment Steps" subflow, but you can clone it and customize the clone. Here's the approach:

Option 1: Clone the Subflow (Recommended)

1. Navigate to: Flow Designer → Subflows → "Service Fulfillment Steps"
2. Click: More Actions (⋮) → Copy Subflow
3. Rename: Custom Service Fulfillment Steps (in your app scope)
4. Inside the loop that iterates sc_service_fulfillment_step, add a Branch action:

IF step.step_type == 'approval'
→ Set Stage: "Waiting for Approval"
→ Execute approval step
→ Set Stage: "Approved" (or loop back on rejection)

ELSE IF step.step_type == 'task'
→ Set Stage: "Work In Progress"
→ Execute task step

ELSE
→ Default processing (existing logic)

5. Add custom stages to the flow:
- Waiting for Approval
- Approved
- Work In Progress
- Keep existing: Service Fulfillment Process, Completed, Closed Incomplete
6. Reroute the parent flow: Update the calling flow (or catalog item's flow) to invoke your custom subflow instead
of the OOB one.

Option 2: Wrapper Flow (Less Invasive)

Instead of cloning, create a wrapper flow that:
1. Calls the OOB subflow as-is
2. Adds a parallel listener using Flow Designer's "Wait for Condition" that monitors the RITM's approval/task
state
3. Updates stages based on current step type

Wrapper Flow:
Stage: "Waiting for Approval"
→ Wait for: sysapproval_approver.state changes
Stage: "Approved"
→ Wait for: sc_task.state = Work In Progress
Stage: "Work In Progress"
→ Call OOB Subflow (handles completion)

Key Tables for Stage Differentiation

┌──────────────────────────────┬───────────┬───────────────────────────────┐
│ Table │ Field │ Values │
├──────────────────────────────┼───────────┼───────────────────────────────┤
│ sc_service_fulfillment_step │ step_type │ approval, task, notification │
├──────────────────────────────┼───────────┼───────────────────────────────┤
│ sc_service_fulfillment_stage │ name │ Your custom stage names │
├──────────────────────────────┼───────────┼───────────────────────────────┤
│ sysapproval_approver │ state │ requested, approved, rejected │
└──────────────────────────────┴───────────┴───────────────────────────────┘

How to Wire It Up

On the Catalog Item or Record Producer:
- Process Engine: Change from Service Fulfillment Steps → your cloned subflow
- Or on the Flow: Replace the subflow action reference

Important Caveats

- Upgrades: Your clone won't receive OOB updates — document what you changed for future merge
- Scope: Clone into a custom app scope so it's tracked in an update set
- Testing: The OOB subflow handles edge cases (cancellation, error states) — preserve those paths in your clone

Recommendation: Option 1 (clone) is cleanest. The OOB subflow is intentionally generic — cloning lets you add
step-type awareness without fighting the platform.