Trigger actions after a specified time

Dear Zammad-Community,

I have recently switched to Zammad as my main ticket system. So far I have set it up nicely and everything works really well, but I do have a question about triggers.

Is there any possiblity to only activate a trigger after a set time has run out? For Example: A customer creates a ticket. Since my customers rent and do not buy hardware from me, I have created a new status “Waiting for Return”. My goal is to set up a trigger system that works as following: After I send out the new hardware, I change the ticket status to “Waiting for Return”, which fires a trigger that changes the prio from normal to low. After exactly one week (with the status change being the start of the timer), I want to get a reminder that the ticket is still on status “Waiting for Return”. In the same step the prio is changed to normal. After another week (with the prio change now marking the start of the new timer), a trigger fires again with the same action as before (reminder + prio to high).

Sadly I have tried everything and still haven’t found a way to make this work. Zammad Support told me that I can only use the Scheduler if I want time based actions, but as you know the scheduler only allows actions like “every monday at 6 perform the following” which doesn’t really help me.

I appreciate every input. Thank you in advance!

Kind regards,

Yes this is possible with the scheduler, I do similar with tickets “waiting for customer”.
You create a scheduled job that runs every day at given times, e.g. everyday at 7:00, 12:00, 16:00, as condition you select ticket status wating for return + last update relative 7 days + priority low. As action you select send e-mail to you with reminder + change priority to normal.
You create a second scheduled job identical to the one above but with condition priority normal and with action send e-mail + priority to high.
This should work without problems and by selecting the priority as condition and changing it in the scheduled job you a) have an update to the ticket which makes the second job work and b) make sure that the trigger doesn’t match the same ticket again.

This is exactly what we are doing. Please note, that ‘last update’ refers to any updates to the ticket, i.e. this includes changes to status and custom fields, internal notes, and so on.

Thank you for the detailed information. I will test this and see if it works. Just two things to add: Since all tickets arrive with the prio normal, the first scheduled job will only function if I set the prio to low manually. Can I simply add a standard trigger that changes the prio to low and fires when I update the status to Waiting for Return?
And “last update relative 7 days”, is that last update after (relative) or before (relative)? Would you mind explaining the difference?


Hmm that is actually not so easy because of the available conditions. Sadly you can’t use the same condition twice in Zammad, we would need a combination of status = updated + status = waiting for return but this is not possible. If you try this with action = updated + status = waiting for return the trigger would fire everytime your scheduled job runs and would change the priority again when we don’t want it to. I think you will have to do this manually.

To make your life easier you could create a makro that combines the steps of changing the status to waiting for return + priority to low + save the changes + close the tab. This way you save some mouseclicks and can’t forget to change the priority.

For this workflow you need last update before (relative) to get tickets that have been updated x days ago.
The option after (relative) is useful in combination with setting the ticket to a reminder x days in the future.

That is exactly what happened when I tested it right now, when I changed the status to waiting for return the trigger fired and changed prio to low, when the scheduled job ran it changed the prio to low again. Guess I will have to do that manually or with a macro, but that’s not too big of a problem. A trigger condition “changed to specific status” would be really nice though.

So just for my clarification: the condition last update before (relative) checks if the ticket has been updated the past 7 days, if it has, the trigger doesn’t fire, and if the condition is true then the trigger will fire. So when I set the time to e.g. last update before (relative) 5 minutes it will check if the ticket has been updated the past five minutes and then will act accordingly?

The first test with the scheduled jobs worked perfectly fine, thank you so much for your help!

Correct, although I prefer to add another condition (just in case): Check for your own (personal/external) e-mail address. In case anything goes wrong the scheduler won’t fire e-mails to customers :wink:

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.