3 strike automation on incident form

[nameisnani]

Hi team ,

Issue Description:

We are facing an issue with the Incident Three-Strike Policy automation in ServiceNow.

• Currently, when the Incident state is set to On Hold and the On Hold Reason is manually updated to Strike 1, Strike 2, or Strike 3, the corresponding notifications are triggered as expected.

• However, we have also implemented automation where:

  • If the user does not reply within 2 business days, the incident automatically moves to Strike 1.

  • If there’s still no response, it then moves to Strike 2, and so on.

Problem:
When the affected user responds in between (and the incident is moved back to In Progress), we are unable to cancel the previously running Flow Context records. Because of this, the earlier flow continues to execute and sends strike notifications even though the user has already replied.

Current Attempt:
We have tried adding a Cancel Action in the flow to stop the previous execution, but it is not working as expected and is interrupting the flow.

Request for Help:
We need guidance on how to properly cancel the pending/previous Flow Context records once the state changes back to In Progress or when the user replies, so that only the correct strike notifications are triggered.

.

(function execute(inputs, outputs) {
    // ... code ...
    var gr = new GlideRecord('sys_flow_context');
    gr.addQuery('source_record', inputs.parameter_id);
    gr.addEncodedQuery('stateINATING,IN_PROGRESS,QUEUED');
    gr.orderByDesc('sys_created_on');
    gr.query();
    gr.next();
    while(gr.next()) {
        sn_fd.FlowAPI.cancel(gr.getUniqueValue(), 'Flow took too long to execute.');
        outputs.parameter_output = 'Success';
    }
})(inputs, outputs);

what was the issue in my configuration , can anyone please help me here .

Thanks  

[JackieZhang]

Actually you can use the scheduled job which running per day to implement it instead of flow.

Just check the state = On Hold and last update date is = 2 business day before. if On Hold Reason is strike 1, then update to strike 2 .... 

[nameisnani]

@JackieZhang 

could you please provide me the steps to achieve my requriment and meets my condition .

[Ankur Bawiskar]

@nameisnani 

I believe it will be somewhat challenging implementing this using flow.

Did you explore scheduled job?

check these

Mastering the Three-Strike Approval Process in ServiceNow: A Step-by-Step Guide 

Low-code/no-code development & implementation of a 3-strike rule 

If my response helped please mark it correct and close the thread so that it benefits future readers.

[Fabian Kunzke]

Hey,

This is a perfect example of something, which should not be a flow (or at least not one single flow). The core reason comes down to one key question:

Is everything done within the flow only influenced by things within the flow itself?

If no (as in your case), then this should not be a single flow (i apply this to every flow). The main reason is that you'd like to prevent parallel flows (flows running at the same time for the same record and - even worse - the same flow running for the same record).

My solution would be to separate this either into multiple flows, or just into different notifications. You need to clearly define, what separates your business logic from your process logic.

As i understood your process logic is:

1) After two days without response, move the current strike up one rank (strike 1 -> strike 2)

2) Every consecutive time for setting it to on-hold, move the strike up one rank

Your actual business logic is straight forward (as i understood):

1) If something moves to on-hold, send a notification

2) If something moves up a strike, send a reminder

Separating process from business logic, enables reusability, but more importantly separates triggers from action. Your action is sending a notification. Your trigger is on-hold & strike ranks. This is important, because in your case, you also have stop-triggers:

Your process logic is interrupted as soon as a response comes in. This is key to understand why your current implementation does not work the way it should. Your flow tries to solve the business logic, but should focus on the process logic first. And here lies your issue (and generally anytime you need to wait for a timeframe):

Your process logic is prioritizing the stop-signal over the wait-for. And this needs to be solved first:

In your flow you are currently waiting for your "go". Wait for the "stop" instead. Therefore, add a "wait for" for the task to move into "in progress" -> this should "stop" your flow. At the same time, you need to wait for 2 business days. This can be archived by the "do in parallel" action.

This way, both of your triggers (wait for 2 business days & back to in progress) become part of your flow. Thus, your flow now contains everything again to make sure nothing from the outside is needed to influence your flow. (and now the question stated above can be answered with "yes")

Short note: You can also get complex and use event triggers to influence the flow running from the outside, but i would not recommend that for this use-case as it would be overkill. Generally speaking: If your solution requires you to cancel flows through a script from outside the flow itself, you are applying the concept of flows incorrectly.

Hope this helps,

Regards

Fabian