+1We have a couple of important events programmed to trigger on Card date a number of days after Date/time of change and a number of minutes after Closure date.
We have been advised that this may fail so we “safeguard” by triggering again after an extra interval or two, like this:
Still, in some cases none of these happen, and the event never triggers.
Is this a known problem, and are there any more robust workarounds than just adding a lot of extra intervals?
+2
In the card's date triggers, we usually only leave one condition. When you add more conditions, TOPdesk automatically links them with "and," meaning that all conditions must be met at that exact moment.
My suggestion is to separate them into three events instead of just one.
+1How can it be the case that all the conditions are AND-ed, if so the event would never trigger with the conditions cited in the image above: It will never happen that it is 2 AND 3 AND 4 minutes after ClosureDate at once.
We have experienced that adding more conditions like these, will catch more calls, but not all of them. There is also the “cost” of having the action sequence run extra times, and process the same calls more times than required.
How can it be the case that all the conditions are AND-ed, if so the event would never trigger with the conditions cited in the image above: It will never happen that it is 2 AND 3 AND 4 minutes after ClosureDate at once.
We have experienced that adding more conditions like these, will catch more calls, but not all of them. There is also the “cost” of having the action sequence run extra times, and process the same calls more times than required.
I agree with
What kind of action do you want to trigger? Are there more than one trigger linked to the linked action? Can you share a full screenshot of the event?
Perhaps a silly question, but for the tickets where the event does not work, are they closed or completed?
+1Oh, but the event definitely does trigger!
That is logged in the Execution log:
There are no other conditions This is it:
The calls are both completed and closed; we do not use the separate “Completed” status.
Oh, but the event definitely does trigger!
That is logged in the Execution log:
There are no other conditions This is it:
The calls are both completed and closed; we do not use the separate “Completed” status.
Oops, you’re right. I have a similar trigger myself for an automatic reminder. Strange that your actions aren’t always being executed. Are you using a Virtual Appliance or SaaS?
I would not recommend using closure date for actions done by operators.
Reason being that for the operator section, the closure date being set is not the same datetime as for when they actually click the save button.
So if an operator sets the incident status to closed, then write a their message it can surely take longer than 3 minutes.
For any operator section action use edit card events, and only use card date events for things that are not tied to immediate actions by operators.
If closuredate was set by service portal or an automation, you will have no problem at all with your current event (except that it will trigger 3 times, unless the linked action archives the card).
Can we have a look at the other event that collided with this one?
+1Thank you,
The reason I didn’t use edit card trigger here is that sometimes another action sequence closes and archives the card. That closure would then trigger this action sequence, which would attempt operation on a newly archived card (and then fail). Not a problem, really, but one would like to avoid those error messages...
+2If you decide to flip over to the edit card solution, I’m thinking you could add a condition in your action sequence for the first step to check if the asset is archived to stop it from firing.
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
