[How to] Flow 3 Strike rule for Incident

[brianlan25]

I’ve seen a couple of community posts related to this, including one today with an approved solution that could easily be adapted. When we first implemented this, our vendor gave us a scheduled job, but it was unreliable. Our second vendor moved the process into a flow, but there were still issues—and the flow became long and complicated because it checked the incident state before sending each reminder email.

Eventually, I found the “Do the following in parallel” action, which made the flow much easier to follow and configure since you no longer need to check the incident state before sending reminder emails.

Trigger Conditions

The trigger is configured on the Incident table with two different conditions that can start the flow:

The second condition was added later. I noticed that technicians were sometimes selecting the wrong On Hold Reason and then correcting it, but because the State didn't change to On Hold again, the flow wasn’t triggering.

Parallel Branch Setup

Next, the flow begins with a “Do the following in parallel” action. The first branch contains a Wait for Condition that monitors for incident state changes that should end the flow.

Here’s a closer look at the condition. I selected every state except On Hold and Resolved. Since the incident is already on hold, it will never change to on hold. And if it changes to Resolved, no more reminders should be sent. There are also additional steps in the flow that run after the incident is marked resolved.

On Hold Reason Check

A second condition can also end the flow: when the technician changes the On Hold Reason to anything other than Awaiting Caller.

Reminder Timing Logic

Next, there are three Wait for Condition steps that wait specific amounts of time. These align with our SLA schedule, where one day equals nine business hours.

The first two steps send reminder notifications that include the original comments. These are configured with Send When = Trigger, so we use the Send Notification action.

The third step updates the incident to Resolved.

Final Closure Step

Finally, we wait one more day and then set the incident to Closed, instead of waiting the usual three days configured in system properties. We shortened this because the caller already had three days to respond, so we didn’t see a reason to give an additional three days to reopen.

You’ll notice this step also ends the flow. If you want to allow more time to reopen the incident, you can skip this and place the End Flow step immediately after marking the incident resolved.