We have added the field “Closing Reason” to our Tickets that only agents can see.
With a “Close & Solved” macro we have implemented, that that field gets filled with the reason “Solved”.
Unfortunately this approach can’t be used for ticket state Pending Closed. So if a pending closed timer is reached the Closing Reason would be “Pending closed reached”.
We tried using Triggers, however their current possibilities do not give us the option that if a ticket that has reached the pending closed timer the custom Closing Reason field gets filled.
Our proposal would be expand the trigger options so you could implement something like:
Ticket changed state1->state2
execute Custom Field = Value
The second part is already possible. It is just not possible for us to monitor from what state the ticket became closed.
Thank you for your response.
With automation you mean the scheduler or trigger?
In both cases I seem to have the same trigger conditions that I can use.
For states it is either “is” or “is not”.
But there is also “Pending till”. I guess that is what you are hinting at.
There are the following options:
However it is not clear to me from the description on how they are to be used nor do I find any description in the documentation. I am guessing before relative or after relative.
Could you provide guidance here on how to use that trigger options correctly?
Edit: Side note: It might be that Zammad takes longer than 10 minutes (between e.g. two runs) to notice the change, normally this shouldn’t happen too often and also not be a big issue on that kind of schedules.
Thank you for the explanation.
To make sure I understood the example correctly, this will check regularly if a ticket has pending closed state for example and if the pending till timer is about to run out in 1 minute it will execute whatever is set below?
Is this correct?
Wouldn’t the regular checking of all tickets put unnecessary load on the server?
you’re close.
This condition filtering finds all pending tickets that reached their pending state for over a minute.
This shouldn’t put too much stress on the Server in my opinion. I know customers doing that without any affection.
The only limitation that may encounter is that if you have more than 2000 Tickets reaching that state, the Scheduler will only work on the first 2000 and continue the work on the other Tickets on the next run.
