1) What is your original issue/pain point you want to solve?
Ticket changes made by an AI agent never notify anybody. When a dispatcher agent
moves a ticket into another group, the agents of that group are not told — no
email, no bell — even when the ticket has no owner and the group notification is
exactly what should have reached them.
This is not a configuration mistake and it cannot be configured away. The
notification is skipped before any user’s notification settings are consulted,
so nothing an agent sets in their profile makes a difference.
2) Which are one or two concrete situations where this problem hurts the most?
-
A dispatcher routes an incoming ticket into a specialist group. That group
is exactly the audience the group notification exists for, and it stays
silent. The ticket has no owner, so nobody feels addressed, and it waits until
somebody happens to look at the right overview. Before the dispatcher was
introduced the same routing was done by hand and everyone was notified — the
automation made the process faster and the hand-off worse. -
A bulk re-categorisation over several hundred tickets, started from a
macro. Here the same notifications would be a flood, and nobody wants them.
The two cases are the same feature and want opposite answers, which is why a
fixed behaviour cannot serve both.
3) Why is it not solvable with the Zammad standard?
There is no setting for it: whether an AI agent’s changes notify is fixed and
identical for every agent type, every trigger, every macro.
A trigger is the only workaround, because triggers do fire on AI agent changes.
But a trigger cannot stand in for the built-in group notification: it does not
know each agent’s own notification preferences, their group selection, or their
out-of-office replacements. Rebuilding that in trigger conditions means either
notifying everyone regardless of their settings, or maintaining a second,
parallel notification configuration that silently drifts from the first.
4) What is your expectation/what do you want to achieve?
I would like to decide per automation whether the ticket changes an AI agent
makes raise notifications — a switch on the trigger, scheduler or macro that
starts the agent, in the same place where the agent is selected.
The behaviour that exists today should stay the default, so nothing changes for
anyone who does not touch the switch. Whether it applies to all notification
channels or only some, and whether it belongs on the automation or on the AI
agent itself, is a design question I am happy to leave open — the point is that
one instance needs both answers for different agents.
Two details suggest the distinction is already close at hand. Triggers were
deliberately made to fire on AI agent changes, while notifications were
deliberately left off: the commit that made AI agent changes raise both
(2026-03-26) was followed one day later by a commit that switched the
notifications back off and kept the triggers. So the two paths are already told
apart in code; what is missing is a way for an administrator to say which one
they want.
Your Zammad environment:
- Average concurrent agent count: varies — I work as a Zammad consultant, so
this does not describe a single instance but customer installations of
different sizes. - Average tickets a day: varies, for the same reason.
- What roles/people are involved: admins and agents at customer installations.
Two customers have used the AI dispatcher widely enough for this to surface,
and both ran into it.
Anything else which you think is useful to understand your use case:
A related request approaches the same question from the opposite side:
Disable notifications when using API
asks for control over notifications caused by API changes, and has been open
since 2023. Automated changes needing a say over notifications is evidently not
limited to AI agents.
Happy hacking 