Help needed with flow for auto closing Incidents after specific period

[AdamUMC]

Hi there,

I have this checkbox that shows up when Incident State = "On Hold" and On Hold Reason = "Awaiting Caller".

What I want is, when the Incident is configured with this State, Reason AND checkbox is CHECKED ON, that the Incident is becoming automatically closed after a while if NO reply has come back, which has removed the Incident from it's "On Hold" + "On Hold Reason" and checked checkbox states.

I've created a flow for this, please see here below. This flow causes me at regular base headache, because it does not work as aspected:

1.) I cannot check contineously if the checkbox is becoming FALSE, to update the Incident (write down "log info- rule" into a Work Note).

2.) It's not possible to create a condition where a value CHANGES (from a specific value) to a specific value. I'm now using "IS FALSE".

3.) STEP 2 from the flow is getting ignored; STEP 9 (same action) is getting processed, but AFTER the first block of 3 minutes in the flow are over, instead of immediately.

This duration of 3 minutes, should be in real life 168 hours / 7 days. For testing purposes I have limited this duration time to 3 minutes. You can imagine that if the Caller re-opens the Incident, we want to know that a.s.a.p. (to confirm the flow is working correctly) instead of waiting 3 minutes or in fact 7 days.

How can I fix this? Is it possible to fix this issue? I have tried to write down a notation in a Work Note with a Business Rule, but that seems not to work. Also, a Business Rule would be just a part of the solution; it cannot end this flow while this is a mandatory step to prevent processing all next steps (autoclosure of the re-opened incident).

Thanks!

[Mark Manders]

Your flow should only be part of the solution. The flow should start on your trigger condition and then wait for 7 days. At that point you check on the status and to see if that is still the same. If so, close the ticket.

Next to that you can have a flow/BR that handles the update coming in from the client. You let that logic set the state/reason/autoclosure fields and the ticket is back on your radar. If you want, you can add the text in the worknotes as well and use a lookup in your first flow to check if that text was added to the sys_journal_field record for this ticket and if that was within 7 days ago (just in case it is set awaiting for a second time).

[AdamUMC]

Hi @Mark Manders , thank you for your reply, altough I don't understand everything very well. 🙂

"Your flow should only be part of the solution. The flow should start on your trigger condition and then wait for 7 days. At that point you check on the status and to see if that is still the same. If so, close the ticket."

But I need to send a reminder after the first block of 7 days, and then wait 7 days again, before closing the ticket. Because of this, the second part of your post will not work, right?

Thanks again.

[Mark Manders]

Your wait conditions in the flow take care of the sending of the email and they validate (after each 7 days) if the notification needs to be send or not. They are checking on what the second part of what I wrote did (or didn't) do.

[AdamUMC]

Btw, this is already configured into a few BR's:

"Next to that you can have a flow/BR that handles the update coming in from the client. You let that logic set the state/reason/autoclosure fields and the ticket is back on your radar."

BR 1:

BR 2:

BR 3:

All of these BR's are "OOTB" BR's. I just added "Autoclosure for On Hold" into the Action tab of each BR (there where was applicable).

Seems the flow is faster with evaluating step 2 (see execution flow), instead of one of the BR's.
If I can solve that, my problem can be solved without the need of any additional actions at the current flow?