Plan requirement
| Subscription | Any plan |
| Access | Admin |
Which tickets an agent can open: four levels, not three, and on Enterprise the setting is not on the profile at all. It is the most consequential access decision you make, and the one most often left at whatever it defaulted to.
Set it
- In Admin Center, click People in the sidebar, then select Team > Team members and open the person.
- Set their ticket access.
- Confirm their group membership matches what you just chose.
- Ask them what they can see.
The four levels
| All tickets | Everything in the account. A decision about specific people, not a default to inherit. |
| Tickets in agent's groups | The usual choice. Broad enough that colleagues can cover for each other, narrow enough that one compromised account does not expose everything. |
| Tickets in agent's org | Only their organisation's tickets. Useful where agents belong to a customer organisation rather than to your own team. |
| Assigned tickets only | Narrow, and usually too narrow. They cannot pick up a colleague's ticket, cannot read what was said before, and have to ask. |
On Enterprise it comes from the custom role
Enterprise plans do not set ticket access in agent profiles. An agent's permissions are determined by their custom role, so the way to change what somebody can open is to change or edit their role.
Which means an Enterprise account cannot give two people in the same role different ticket access. If you need that, they need different roles, and it is better to discover this while designing the roles than afterwards.
A CC goes around all of it
Zendesk is explicit about this and it undoes careful work: whatever an agent's ticket access says, CC'ing them on a ticket sends them email notifications of updates to it. The restriction governs what they can open, not what can be sent to them.
How far that goes depends on which route is used. A CC'd agent gets the public conversation, and an internal note only where they are explicitly on that note. A follower gets both, every time. So following is the wider hole of the two, and it is the one nobody thinks of as granting access.
So a group-based scheme holds until a colleague adds somebody to a thread. That is not a reason to ban CCs; it is a reason to know that the access setting is a floor rather than a wall, and to say so when somebody asks whether a team can be kept out of a sensitive queue.
Why it matters more than it looks
Tickets hold what customers told you, including things they would not want a wider audience reading. Access is not only a security control, it is a promise to the customer, and it is the one thing in this list you cannot walk back after the fact.
Check it after any reorganisation
People move between teams and keep the access from the old one. Nobody notices, because having too much access never produces a complaint.
And verify with the person rather than with the screen. Reading the setting tells you what you configured; watching them work tells you what you achieved.
Comments
0 comments
Article is closed for comments.