Three‑strike reminder logic when Incident is On Hold – Awaiting Caller

[nameisnani]

Hi Team ,

Problem Statement

We have implemented a 3‑Strike rule using Flow Designer for Incidents that are put On Hold with reason “Awaiting Caller”.

Expected behavior

• When the Incident is Resolved or Closed, the strike monitoring must stop immediately.
• No reminders, comments, or emails should be triggered after resolution.

Actual behavior

• Even after the Incident is Resolved, the flow continues to execute after the Wait activities.
• Strike reminders and emails are posted after the incident is already resolved.

---

Flow Design (High Level)

The flow is triggered on:

• Record Updated
• State = On Hold
• On hold reason = Awaiting Caller

The logic is roughly:

1. Set strike/order
2. Wait 2 min
3. Send 1st reminder
4. Wait 4 min
5. Send 2nd reminder
6. Wait 4 min
7. Send final reminder + email
8. Update incident on final strike

There are multiple Wait actions using business hours and holidays.

steps 1

Now in the production we are getting an issue that  even after reslvoing the incident strike sent

How to fix this issue - can any one please help me 

Business rules 

client scirp 

How should i fix this issue can any one please help me 

any scripts i need to update 

@Ankur Bawiskar need your support here 

[nameisnani · Accepted solution]

@Ankur Bawiskar  FYI Info 

[nameisnani]

@Ankur Bawiskar 

One more thing also noticed that 

I kept this incident Onhold and awaitng caller - after some time i changed in progress 

still strike has been triggered 

@Ankur Bawiskar  could u please help me here please 

[Mark Manders]

That's what I already mentioned: you need to put a safeguard in, so you know if the ticket was changed or not. 

[nameisnani]

@Ankur Bawiskar 

can u please help me here 

[Mark Manders]

Why don't you do a simple lookup before before every strike? A check on the trigger record may check on the state it was when it triggered. If you lookup the record again to see if the state is STILL on that same state, it should work.

Also: think about any logic when there is an update and it goes back to on hold. Do you have safeguards in place that your flow recognizes these?