How to trace and cancel Flow Designer executions that generated approval records

[JMH2]

Hi Community,

I’m working on a use case in Flow Designer where I need to programmatically track and cancel a flow execution that created approval records.

Scenario:

• When a dmn_demand moves from Screening to Qualified, a Flow Designer flow ("Create Approval for Tech Demand") generates approval records (using the Ask for Approval action) for all users in the related Portfolio group.

• If the Portfolio group is updated on the Demand because the initial group was incorrect, another flow ("Update Approvals for Tech Demand") is triggered to:

  • Mark existing approvals as No Longer Required, and

  • Generate a new set of approvals for the updated group.

Problem:
The original flow ("Create Approval for Tech Demand") stays stuck waiting. This is because the approval state being set to No Longer Required doesn’t satisfy the Approve/Reject condition that allows the flow to proceed.

I need to reliably:

1. Trace back from a given sysapproval_approver record to the sys_flow_execution that created it.

2. Cancel that flow execution to prevent it hanging indefinitely on the Ask for Approval step.

What I’ve tried so far:

• Added a custom field (u_generated_from) on sysapproval_approver.

• Wrote a Business Rule on insert of approval records that looks up the most recent sys_flow_execution record in sys_flow_context / sys_hub_flow_context to populate u_generated_from.
• The issue is that there’s no direct reference between sys_flow_execution and the approval record, so my approach only works intermittently.

Here's the Business Rule:

(function executeRule(current, previous /*null when async*/) {

	gs.sleep(10000);
    if (gs.getSession().isInteractive() == false) {
        gs.info("Approval Tracking: Starting population for approval: " + current.sys_id);

        var contextGR = new GlideRecord('sys_flow_context');
        contextGR.addQuery('state', 'WAITING');
        contextGR.orderByDesc('sys_created_on');
        contextGR.query();

        if (contextGR.next()) {
            gs.info("Approval Tracking: Found flow context: " + contextGR.sys_id + " for approval: " + current.sys_id);
            current.u_generated_from = contextGR.sys_id;
        } else {
            gs.warn("Approval Tracking: No active flow context found for approval: " + current.sys_id);
        }
    } else {
        gs.info("Approval Tracking: Skipping population for interactive session (approval: " + current.sys_id + ")");
    }

})(current, previous);

Questions for the community:
- Is there a reliable way to capture and store the sys_id of the flow execution that created an approval record?
- Given a sys_flow_execution.sys_id, is there an out-of-the-box API or pattern to cancel the flow cleanly (e.g., via FlowAPI, FlowRuntime or directly from sys_flow_execution)?
- Has anyone built a reusable pattern for tracking approval-generating flows and cancelling them mid-execution?

We’re currently on Xanadu (upgrading to Yokohama in 2 weeks). The use case is specific to Demands for now, but we’d like to generalise this to all approval records in future.

Would love to hear from anyone who’s dug into sys_flow_execution, sys_flow_context, or sys_hub_flow_context for similar use cases.

Thanks,
Jasmin

[Community Alums]

hi @JMH2 ,

🧩 Why this is tricky

• The Ask for Approval action in Flow Designer doesn’t automatically keep a direct reference back to sys_flow_context on the sysapproval_approver record.

• Approval records themselves (sysapproval_approver) only point to the record they’re for (like the Demand), not to the Flow execution that created them.

• Flow executions (sys_flow_execution) get cleaned up after a while (based on retention policy), so historical tracking can get messy.

---

✅ What actually works

1️⃣ Capture the context during creation, instead of after

Instead of relying on a Business Rule that tries to find the most recent flow context after the approval is created, do it inside the Flow Designer itself:

• Add an Action right after Ask for Approval to write back the Flow Context Sys ID to the Demand (or to a custom field or related table).

• You can get the current flow execution Sys ID via the built-in Flow variables:

  • actions.sys_flow_context.sys_id (depends on the version — in some, you can pull the context directly).

• Store that in a custom field (e.g., u_flow_context on Demand or even in a small custom tracking table with demand, flow_context, approval_sys_id).

That way, you always know which context created which approvals, reliably.

---

2️⃣ Cancelling a running Flow execution

Once you have the sys_flow_context (or sys_flow_execution) Sys ID:

• There is an OOTB API:

  javascript

  CopyEdit

  var runtime = new sn_fd.FlowAPI().getFlowRuntime('<flow_context_sys_id>'); runtime.cancel();

• This cleanly stops the Flow execution, including the Wait for Approval step, without leaving it in "WAITING" forever.

You can do this in a Script Action, Business Rule, or a separate Subflow that takes the Flow Context Sys ID as input.

---

3️⃣ General reusable pattern

I've helped teams build something like this:

• Create a small custom table, e.g., u_flow_approval_tracker:

  • Fields: approval_sys_id, flow_context_sys_id, target_table, target_sys_id

• In the Flow that creates approvals:

  • Immediately insert a record into this table after each approval is created.

• Later, if you detect the approvals are "No longer required" or want to regenerate:

  • Look up the flow_context_sys_id from this table.

  • Use FlowAPI().getFlowRuntime().cancel() to stop the original flow.

This avoids relying on timing tricks like gs.sleep or "most recent context."

---

4️⃣ Be careful with parallel approvals

If you have multiple approvals created from the same Flow, you'll want to track all of them.
Either:

• Track at the Flow Context level (one context created several approvals).

[JMH2]

The flow stays sitting in 'Ask for Approval' so I can't do anything until that action is completed (i.e. approved or rejected). There is no way to continue on with the flow without having this response

[Mark Manders]

Why not add an 'end flow' within the flow if the approvals are 'no longer required'? No other scripts needed, just handled within the same flow.

[JMH2]

Because it forever sits in 'Ask for Approval', the flow doesn't continue until the approval is approved or rejected