I have a process that needs to send an email every 2 hours until a ticket is closed. I am currently doing this with the delay parameter that is part of the loop operator, which works as intended.
When we ran the built in Process Duration Status Report this process shows as taking a very long time which made me question the resources being used and if this is efficient. My guess is that this report just goes off status which stays in the Running state the entire time this process is running. My hope is that with a two hour delay that delay is implemented in an efficient mean behind the scenes.
Does anyone have any insight into this?
If you are concerned about the length of time an individual process is running, you could set up the process to call itself as detached after a certain number of tries. For example:
Say the definition is called Send-Email-Reminder:
1) Process Instance starts and begins delay for 2 hours
2) Delay ends and email is sent. Process delays again for 2 hours.
3) After x number of emails, process instance will call a detached instance of Send-Email Reminder and terminate
However, If you are using Service Desk Manager for the ticketing, you could use SLA Events for these reminders. This would be more efficient and would not need Process Automation.
What do you mean by taking a very long time? Do the first couple of loops take seconds and the later ones minutes?
If you are talking about the overall process duration, then yes, it stays in a running state the entire time so it is counting each 2 hour loop as 2 hours worth of 'processing' time and would be reflected in the overall duration.
Even I am trying to do this. I want a delay of 10 minutes, check database for the rows, if not found another delay of 10 minutes and so on until it finds the rows in the database.
But if say even after 2 hours there is nothing in the data base, my loop will keep going on which I do not want.
I want my loop to go on for maximum of 2 hours(say 12 loops) & then fail the test.
How can I do this?
Thanks for the suggestions.
We had talked about using SLA Events, email contacts are currently being pulled from a system outside of Service Desk which I believe requires us to use PAM to generate them.
Yes I am talking about the duration in the duration report being very large. They delay as expected in the process and everything is working correctly.
My only concern was about efficiency since these processes have not been a short lived as I had hoped they would be when I implemented it. I have some of these processes that have been running for over a month, sending emails every 2 hours.
In this case, you would check the "While loop" box in the Loop Properties and put your while condition in the "Repeat Count" box. (Yes this is a poorly named multi-use property).
Another thought is to have the SLA Event call the Process Automation process, instead of the category or activity association. This would save you having to do the delay in the process but would allow you to reference that external source for the recipients.
Every 2 hours for over a month! That's more than 360 emails for one thing. I imagine that, by now, the recipient either deletes them without reading or has set up a rule on their inbox to delete these emails as soon as they arrive.
Soliciting process compliance using the "nag them" approach rarely works. I suggest another approach. Perhaps escalating up the management chain after a certain amount of time?
Reminds me of the joke post - Ladies, when we husbands say we will do something, we will do it. You don't have to nag us every 3 months.
Wow, that is quite a lot of emails.
Maybe you could implement something where after a certain number of loops or some time frame you switch to a different loop that sends an email once a day?
This is probably the best of both world. I will look into this further. Thanks for the suggestion!
Believe me, I agree. In this case, it is a contractual SLA obligation and the customer, at least at the macro level, is very on top of this an questions any missed emails. Gotta love government customers...