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.