- What is your original issue/pain point you want to solve?
Zammad’s permission model is entirely group-based: an agent’s access to tickets comes from their group membership and the access level (Full/Change/Create/Read/Overview) granted for that whole group. There is no way to grant someone access to only a single ticket. The “Owner” field doesn’t help here either — it just marks who’s currently working a ticket, but you can only become Owner if you already have group-level access, so it grants no independent permission of its own.
As soon as you need to give someone outside your regular agent pool access to work on one specific ticket, the only option today is to make them a full agent of that ticket’s group — which immediately exposes them to every other ticket in that group, including ones that have nothing to do with them.
- Which are one or two concrete situations where this problem hurts the most?
We send hardware repairs to an external contractor company. Right now, the only way to give that contractor access to the ticket they need to work on is to make them a full agent in the “Hardware” group. That means they can also see every other ticket in that group — tickets from other customers, and potentially tickets involving other contractors or internal discussions that are none of their business. There’s no way to say “this person may only ever see the one ticket they’ve been handed.”
- Why is it not solvable with the Zammad standard?
Because access control in Zammad is scoped to groups, not to individual tickets. There is no concept of a permission that applies only to “tickets where I am named as X.” The closest existing mechanism, group access levels, is all-or-nothing for every ticket in that group, and the Owner field carries no permission semantics of its own — it’s just a label on top of access you already have via your group.
- What is your expectation/what do you want to achieve?
Introduce a new, ticket-scoped role — a “Collaborator” — as a second assignment field alongside the existing “Owner”:
- A Collaborator has no group-level access at all. Their visibility is limited strictly to the individual tickets where they are named as Collaborator. If they’re removed as Collaborator, they lose access to that ticket again.
- Any agent already working the ticket can assign a Collaborator, the same way Owner is assigned today.
- On a ticket where they’re set as Collaborator, their permissions are a restricted subset of a normal agent’s: they can view and reply to the ticket, but they cannot see internal notes, cannot reassign the ticket or change its group/Owner, and cannot see the customer’s other tickets or profile.
- The feature should be opt-in per group, so admins can enable the “Collaborator” field only where it’s needed (e.g. a group used for outsourced repairs) without changing behavior anywhere else.
This would let organizations safely loop in external contractors, vendors, or occasional internal specialists on individual tickets, without giving them the broad group access that full agent permissions require today.
If there is any more useful information, feel free to share it all (e.g.: mockup screenshots, if something is UI related, or the API URL/documentation URL for a service you need a connection to).
This request comes from the product side, based on a recurring pattern (external contractors/vendors needing narrow, per-ticket access) rather than one specific deployment’s numbers.
If you read this thread and like that idea, do not forget to give the first article a like as well.