Plan requirement
| Subscription | Any plan |
| Also required | Workforce Management or Workforce Engagement Management |
| Access | Admin |
Two roles come as standard, everything between them is one you build, and Zendesk admins already have the top one.
Two roles come as standard
| Agent | By default, access to the Schedule in Zendesk Support and nothing else, within their own teams, locations and workstreams. |
| Admin | Every feature, all teams, locations and workstreams, and the right to say who has which role. |
Anything between the two is a role you create. Team lead, Manager and Supervisor are common examples, and they are custom roles rather than something Zendesk provides.
Permissions belong to roles, not people
You configure what a role may do, and everyone assigned to it inherits that. So a team lead who needs one extra permission means either changing it for every team lead or making a second role, and that is worth deciding before you have six of them.
Zendesk admins are already Workforce Management admins
Automatically, without anybody assigning it. So the set of people who can reconfigure your workforce management is the same set who administer Support, whether or not that is what you intended.
Worth checking against your list of Support admins before you assume workforce data is separately held.
User management no longer means the Admin role
Until 9 September 2026 the team members page was reachable only by admins, so letting somebody manage user settings meant handing them everything. A custom role can now carry its own team members permission at one of three levels: No access, View, or View and manage, the last covering team, workstream, task lock and auto-tracking assignments.
It can also be scoped to a manager's own team, workstream or location, which is what makes it usable for an outsourcing partner or an HR manager who should see their own people and nobody else. Permission changes are recorded in the audit log.
The permissions worth thinking about
- Approving time off. Usually the team lead, sometimes a manager outside support.
- Publishing schedules. Narrow this: a published schedule is a commitment to people.
- Seeing other teams, which is rarely necessary and often uncomfortable.
- Editing tracked time, which changes the record of what somebody did.
- Reaching the team members page, which since 9 September 2026 is a permission of its own rather than something only an admin has.
That last one deserves care
Being able to edit tracked time means being able to change the record of somebody's working day. Keep it with the people who are accountable for the schedule, and expect to be asked about it.
Assigning somebody to a team can widen what others see
This one runs against the instinct. An agent who belongs to no team is visible to every role. Put them in a team and every role whose scope covers that team inherits that same visibility, so an assignment meant to narrow access can open it instead.
Worth checking the scopes before you tidy up the team list, not after.
Agents should see their own data
Their schedule, their adherence, their balance. It is about them, and withholding it creates more suspicion than the numbers ever would.
Start standard
The three roles cover most organisations. Build a custom role only when a real job does not fit, not to fine-tune a permission somebody asked about once.
Comments
0 comments
Article is closed for comments.