Need help in running Flow Designer flow

nameisnani · yesterday

Hi Community,

Looking for guidance on cancelling a running Flow Designer flow via a Business Rule. Would really appreciate any help or pointers!

---

📌 BACKGROUND

We have a '3 Strike Rule' flow (Flow Designer) that triggers when an incident is placed On Hold with reason = Awaiting Caller. The flow sends strike notifications at scheduled intervals and auto-resolves the incident if there is no response.

---

❓ THE PROBLEM

If an agent updates the incident before the flow completes — either by changing the state away from On Hold, or by changing the hold reason from Awaiting Caller to something else (e.g. Awaiting Evidence or Awaiting Change) — the flow continues running and sends stale strike notifications even though the situation has already changed.

We want the flow to cancel automatically in two scenarios:

1. State changes from On Hold (Awaiting Caller) → any other state (In Progress, Resolved, etc.)
2. State stays On Hold but reason changes from Awaiting Caller → Awaiting Evidence or Awaiting Change

---

🙏 WHAT WE NEED HELP WITH

• Is a Business Rule the right approach to cancel a running Flow Designer flow, or is there a better way?
• Has anyone used sn_fd.FlowAPI.cancelFlowForRecord() for this — any gotchas to watch out for?
• Any advice on filter conditions or script logic to handle the two scenarios above cleanly?

---

We are on a recent ServiceNow release. Any guidance, examples, or links to docs would be hugely appreciated!

#FlowDesigner #BusinessRules #Incident #OnHold #Automation

rahulkoheda · yesterday

Hi @nameisnani
Approach: Re-validate state before each strike notification

Before every "send strike notification" action in your flow, add an IF (Flow Logic) step that re-checks the current state of the incident record:

Condition: Incident.State == On Hold AND Incident.Hold Reason == Awaiting Caller

If this condition evaluates to true → proceed and send the strike notification.
If it evaluates to false → branch into an End step (or just let that branch terminate) instead of sending the notification.

You'd repeat this check before each strike (Strike 1, Strike 2, Strike 3, and before the auto-resolve action), so that at every interval the flow re-confirms the incident is still in the state that justifies sending the next notification.

Why this works for both your scenarios

State changes away from On Hold → the first part of the condition fails → flow stops sending further strikes.
State stays On Hold but Hold Reason changes (e.g., to Awaiting Evidence or Awaiting Change) → the second part of the condition fails → flow stops sending further strikes.

Siddhesh Jadhav · yesterday

Hi @nameisnani ,

Yes, a Business Rule is a good approach for this requirement.

You can create an After Update Business Rule on the Incident table and check for the following scenarios:

The incident state changes from On Hold (Awaiting Caller) to any other state.
The incident remains On Hold, but the On Hold Reason changes from Awaiting Caller to another reason such as Awaiting Evidence or Awaiting Change.

In the Business Rule, you can use

sn_fd.FlowAPI.cancelFlowForRecord()

to cancel the running Flow Designer execution for that specific incident record when either of the above conditions is met.

Probable Impact:

Prevents stale strike notifications from being sent after the incident conditions have changed.
Avoids unintended auto-resolution of incidents.
Reduces unnecessary flow executions and keeps the process aligned with the current incident state.
Improves the overall user and agent experience by ensuring notifications are only sent when they are still relevant.

I would recommend thoroughly testing this in a lower environment, especially if there is a possibility of multiple flow contexts running against the same record.

Thanks and Regards,
Siddhesh Jadhav

Please mark this answer as Helpful and Accept it if it helps resolve your question.

nameisnani · yesterday

Hi @Siddhesh Jadhav

I have configured this Businesss rule

before update buinsess rule

(function executeRule(current, previous) {

    var FLOW_NAME      = '3 Strike Rule_VS';   // Must match exact internal name of your flow
    var ON_HOLD_STATE  = '3';                  // ServiceNow default On Hold state value
    var AWAITING_CALLER = 'Awaiting Caller';

    var prevState      = previous.state.toString();
    var currState      = current.state.toString();
    var prevHoldReason = previous.hold_reason.getDisplayValue();
    var currHoldReason = current.hold_reason.getDisplayValue();

    // ─────────────────────────────────────────────────────────
    // LOGIC 1: State moved away from On Hold
    //   Previous : On Hold + Awaiting Caller
    //   Current  : ANY state other than On Hold
    // ─────────────────────────────────────────────────────────
    var logic1 = (prevState      === ON_HOLD_STATE &&
                  prevHoldReason === AWAITING_CALLER &&
                  currState      !== ON_HOLD_STATE);

    // ─────────────────────────────────────────────────────────
    // LOGIC 2: Stayed On Hold but reason changed
    //   Previous : On Hold + Awaiting Caller
    //   Current  : On Hold + Awaiting Evidence OR Awaiting Change
    // ─────────────────────────────────────────────────────────
    var cancelReasons = ['Awaiting Evidence', 'Awaiting Change'];

    var logic2 = (prevState      === ON_HOLD_STATE &&
                  currState      === ON_HOLD_STATE &&
                  prevHoldReason === AWAITING_CALLER &&
                  cancelReasons.indexOf(currHoldReason) !== -1);

    // ─────────────────────────────────────────────────────────
    // If either logic matches → cancel flow + add work note
    // ─────────────────────────────────────────────────────────
    if (logic1 || logic2) {

        // Cancel the running flow instance
        try {
            sn_fd.FlowAPI.cancelFlowForRecord(
                FLOW_NAME,
                current.getTableName(),
                current.sys_id.toString()
            );
        } catch (e) {
            gs.warn('3 Strike Rule BR: Could not cancel flow. ' + e.message);
        }

        // Build work note text
        var noteMsg;
        if (logic1) {
            noteMsg = '[3 Strike Rule] On Hold reason moved from Awaiting Caller' +
                      ' - state changed to ' + current.state.getDisplayValue() +
                      '. Existing flow has been cancelled.';
        } else {
            noteMsg = '[3 Strike Rule] On Hold reason moved from ' +
                      prevHoldReason + ' to ' + currHoldReason +
                      '. Existing flow has been cancelled.';
        }

        // Write work note
        current.work_notes = noteMsg;
    }

})(current, previous);

@Siddhesh Jadhav anything worng in my buiness ewhile doing testing i have moved state awaitng caller to in progress - exisiting flow is not getting canclled

could u please help me with the updated script .

Siddhesh Jadhav · yesterday

Hi @nameisnani ,

I just checked the latest documentation, and one thing stands out. The FlowAPI.cancel() method requires the Flow Context (Execution Details) sys_id, not the flow name.

If cancelFlowForRecord() is not cancelling the execution in your case, I would suggest verifying whether your release supports this API as expected. Otherwise, you may need to:

Query the active Flow Context/Execution Details record for your Incident and flow.
Retrieve the context sys_id of the running execution.
Use sn_fd.FlowAPI.cancel(contextSysId, 'Incident no longer Awaiting Caller') to cancel that specific execution.

Also, I would still recommend moving this to an After Update Business Rule and adding some logging to confirm that your conditions are evaluating to true.

From your description, I don't see anything obviously wrong with your conditional logic. The issue seems more related to how the flow execution is being identified and cancelled rather than the state/hold reason checks themselves.

Thanks and Regards,
Siddhesh Jadhav

Please mark this answer as Helpful and Accept it if it helps resolve your question.