Hi everyone,
I wanted to share something I’ve been trying to build in Zammad over the past few weeks, because I kept running into the same two walls and I suspect I’m not the only one.
The idea was to create a manually managed priority ranking inside Zammad. My team works with over 100 open tickets at any time and we wanted a simple “Top 30” list where agents assign a numeric position (1 to 30) to a ticket. When a new ticket gets placed on an already occupied position, everything below it should shift down automatically.
On paper this sounds straightforward. In practice, it turned out to be impossible to implement cleanly within Zammad’s current automation system, and I think the reason is worth discussing.
The first issue: triggers and schedulers only ever touch the ticket they’re acting on.
When an agent sets Ticket A to position 5, a trigger fires on Ticket A. But Ticket B, which was already sitting on position 5, can’t be touched by that trigger. There’s simply no way to say “find all other tickets matching condition X and apply change Y to them.” Schedulers can do this in principle, since they run against all matching tickets, but they’re time-based with a minimum granularity of one hour per slot. If a cascade is five levels deep, you’re looking at up to five hours before it’s resolved. That’s not workable in a real support environment.
The second issue: you can’t copy a field value from one field to another dynamically.
Actions in triggers and schedulers can only set a field to a fixed, predefined value. There’s no way to say “set field B to whatever the current value of field A is.” For anything that needs a helper or mirror field to track intermediate state during an automation chain, this becomes a real blocker.
I’m not sure what the right solution looks like from an implementation perspective, but I can think of a few directions that would help:
Allowing triggers or schedulers to optionally apply their actions not only to the ticket that triggered them, but also to other tickets matching a separate set of conditions. This would be a bigger change but would open up a lot of automation scenarios that are currently impossible.
Allowing field actions to reference another field’s value at runtime instead of only accepting static input. Even this smaller change would make a significant difference for more complex workflows.
A more scoped option could be a dedicated propagation or cascade action type that pushes a field change to other tickets sharing a specific field value, without needing full cross-ticket query logic.
I think the underlying need, coordinating state across multiple tickets through automation, is something that goes beyond my specific use case. Parent/child relationships, SLA dependencies, ranked queues, any team dealing with these will eventually hit the same limitations.
Happy to go into more detail if useful. Curious whether others have run into similar situations.
Thanks