Zendesk Roles & Permissions Explained

This guide is the plain-English map of the Zendesk permission model: the three user types, the predefined staff roles and what each one can and can't do, custom roles on Enterprise, the end-user settings that control your customers, and how all of it ties back to seat billing. Everything here is verified against Zendesk's own documentation (June 2026) — but Zendesk evolves, so confirm specifics in your own account before relying on them.

Start with the three user types

Before any individual role, Zendesk splits everyone who touches your account into a small number of user types. This is the foundation; the named roles all live inside it.

• End users (your customers). These are the people who submit and track tickets. They can communicate with your team publicly, see their own requests in the help center, and not much else. End users have no access to agent or admin tooling, and — importantly — their comments are always public; an end user can never leave a private/internal note. They don't cost you anything and there's no practical limit on how many you have.
• Team members (your staff). A team member is anyone you add to the account who isn't an end user. In Support, a team member is an account owner, an administrator, an agent, a light agent, a contributor, or someone on a custom role. Team members are who consume your paid seats (with the exceptions we'll cover) and who can see internal notes, work tickets, and configure the account.
• The account owner. A special case worth calling out on its own. The account owner is one specific person — a type of administrator with extra powers around the subscription itself: changing the plan, managing billing and payment, and certain account-level changes no other admin can make. There is exactly one account owner per account, though ownership can be reassigned to another admin when, say, the original owner leaves the company.

A clean mental model: end users are the outside world, team members are the inside world, and the account owner is the one team member who also holds the keys to the contract.

The predefined team-member roles

Inside "team member," Zendesk ships a set of standard roles. On Team, Growth, and Professional plans these are the roles you assign directly; on Enterprise they become starting points for custom roles (more on that below).

Before the role-by-role detail, here's the whole model on one page. The table below maps each role against the eight permissions that matter most in practice — verified against Zendesk's standard user roles documentation:

¹ End users see only their own requests (or, with a shared organization, their company's). ² Light agents and contributors see tickets within their groups and can be CC'd; the contributor footprint is the narrower of the two. ³ Admins scope which tickets an agent sees — all, group-only, organization-only, or assigned-only. ⁴ Agents can be granted view-only Explore access, but creating and editing reports is an admin capability.

Agent

The agent is the workhorse role — the people actually answering customers. A standard agent can:

• View and update tickets — though admins control which tickets each agent sees (all tickets, only tickets in their groups, only their organization's, or only ones assigned to them).
• Reply publicly to customers and add internal notes to coordinate with colleagues.
• Create personal macros and views, and add, edit, or delete end-user profiles.
• Moderate help center content where allowed.

What an agent can't do is just as important: agents cannot manage account settings, create or edit business rules (triggers, automations, SLAs), or build reports in Explore. Those are admin powers. An agent's world is the Agent Workspace and the tickets in it.

Admin

An admin is an agent with the settings keys. Admins can do everything an agent can, plus:

• Access all tickets in the account, regardless of group.
• Manage account and channel settings (everything except billing).
• Create and edit business rules — triggers, automations, SLAs, and the like.
• Create and edit reports in Explore.
• Add and manage users, create groups, and install apps from the Marketplace.

The one thing a regular admin can't touch is the subscription and billing — that's reserved for the account owner. Because admins can reshape how the whole account behaves, the number of admins should be small and deliberate.

Light agent and contributor

This is where most teams overspend before they understand the model. Not everyone who needs to see a ticket needs a full agent seat.

• A light agent can be CC'd on tickets, view tickets within their groups, and add internal (private) comments — but they cannot reply publicly to customers, be assigned tickets, or edit ticket properties. They're built for the colleague in engineering, finance, or product who needs to weigh in privately without becoming a front-line support agent. Light agents require a Suite Growth plan or above, or the Light Agents / Collaboration add-on on Support plans. We go deep on exactly what they can and can't do in what is a Zendesk light agent.
• A contributor is an even more limited collaboration role — it can view and add private comments to tickets within its groups, with a narrower footprint than a light agent.

The key billing fact: light agents and contributors are typically free and do not consume a paid agent seat — your Suite plan includes a generous pool of them (Professional includes up to 100 light agents, Enterprise up to 1,000, and Enterprise Plus up to 5,000, per Zendesk's seat documentation). They only start costing you a seat if you upgrade them to a full agent role, or if their role in an adjacent product (Chat, Knowledge, or Analytics) is set to a paid level. That's the lever for keeping a large, collaborative organization on Zendesk without paying agent prices for everyone who occasionally reads a ticket.

Custom roles: the Enterprise way

On Enterprise and Enterprise Plus plans, the predefined roles give way to something far more granular: custom roles. Instead of "agent or admin," you define exactly what a role can do across dozens of individual permissions.

A few things to know:

• Enterprise replaces the standard agent role with custom agent roles. Rather than one flat "agent," you build roles like Tier 1 Agent (can solve and comment but not delete tickets), Team Lead (can also edit views and macros for the group), or Reporting Analyst (read tickets plus full Explore access, but can't change settings).
• You don't start from scratch. Zendesk ships a set of predefined "system custom roles" that mirror common support job functions. You can use them as-is or clone one and tweak the permissions — usually the fastest path.
• The permission sets are genuinely fine-grained. You toggle what a role can do with tickets (view scope, edit, delete, merge, redact), people, business rules, macros, views, reporting, channels, apps, and more — so access maps to real responsibilities instead of a blunt all-or-nothing switch.
• There's a ceiling. You can create up to 197 custom roles on an account, which is far more than almost any org needs.

Custom roles are the mechanism that makes least privilege practical at scale: give each person exactly the access their job requires and nothing more.

Roles aren't only in Support: per-product access

Everything above governs Zendesk Support — but Support is one product in a suite. The other products carry their own roles, set independently per team member under Admin Center > People > Team, in each person's profile under "Roles and access". Someone can be a full agent in Support while holding a different (or no) role in another product:

• Guide / Knowledge has its own roles — Admin, Agent, and Viewer — controlling who can create, edit, and publish help center articles.
• Chat / messaging uses Admin, Agent, and Agent (limited) (plus custom Chat roles), governing live-chat and messaging access.
• Talk (voice) has Admin, Team lead, and Agent roles for the phone channel.
• Explore (analytics) splits access into Admin, Editor, and Viewer — which is what actually decides whether someone can build dashboards versus just read them.

The practical upshot: a person's "role" in Zendesk isn't a single switch. A light agent in Support might still be an Editor in Explore or an Admin in Guide — and, as noted earlier, a paid role in an adjacent product is one of the few things that turns an otherwise-free light agent into a billable seat. When you audit access, check each product, not just Support.

End-user permissions: controlling your customers

Roles govern your staff, but you also control what the outside world can do. These live under Admin Center > People > Configuration > End users, and they shape how customers reach you.

• Who can submit tickets. The "Anybody can submit tickets" setting decides whether anyone — registered or not — can open a request. Turn it off and only users you've added can submit, which suits private or internal-only help desks.
• Whether they have to register. With "Ask users to register" enabled, customers verify their email before a request becomes a real ticket. Leave registration off and anonymous submissions still arrive, but unverified ones land as suspended tickets to keep spam out.
• Whether customers can see each other's tickets. By default, an end user sees only their own requests. But you can configure a shared organization so that everyone in a company can view (and optionally comment on) all of that organization's tickets — useful for B2B accounts where colleagues track shared issues.

Help center visibility (open, restricted to signed-in users, or closed) is controlled separately, so you can decouple "who can read our content" from "who can file a ticket."

A note on the Roles admin UI. The Roles page lives in Admin Center behind a login, so we're describing it rather than showing a screenshot. To find it yourself: Admin Center > People > Team > Roles, where you'll see the standard roles and (on Enterprise) the Create role button that opens the granular permission editor.

How roles, seats, and collaboration fit together

Tie the threads together and a practical model emerges for staffing a Zendesk account economically:

• Full agents and admins consume paid seats — keep this group to the people who actually work tickets with customers and the few who must configure the account.
• Light agents and contributors are your free collaboration tier — loop in subject-matter experts, managers, and cross-functional colleagues without buying seats, as long as they only need to view and comment internally.
• Custom roles (Enterprise) let you slice the paid-agent population into precise job functions, so a junior agent can't delete tickets and a reporting analyst can't rewrite your triggers.
• End-user settings decide how the outside world gets in.

The honest watch-out: light agents and contributors are limited by design. The moment someone needs to reply to a customer or own a ticket, they need a full agent seat — so map needs to roles before you assign, not after.

Best practices (and common mistakes)

A few habits separate clean Zendesk accounts from messy ones:

• Default to least privilege. Start people on the most limited role that lets them do their job and add permissions when there's a real need. It's far easier than clawing back access later.
• Keep admins few. Every admin can rewrite your business rules and settings. A handful of trusted admins prevents the "why did the trigger change?" mystery.
• Use light agents instead of agent seats for collaborators. The single most common — and most expensive — mistake is buying full seats for people who only read and comment internally. That's exactly what light agents are for.
• On Enterprise, clone a system role rather than building from zero. Faster, and less likely to leave a dangerous permission toggled on by accident.
• Right-size end-user access early. Decide up front whether anyone can submit tickets and whether registration is required; flipping it later changes who can reach you overnight.
• Audit roles periodically. People change teams. Review who's an admin and who's on which custom role a couple of times a year so access still matches reality.

Where an AI agent fits into the permission model

Roles aren't only about humans anymore. When you add an AI layer to Zendesk, it acts through the same permission and API surface your staff do — so it's worth thinking about it as another actor with a scoped role.

An AI agent layer like Macha sits on top of your existing Zendesk (it's not a help desk and not a Zendesk replacement). It connects via the Zendesk API and operates within the permissions you grant it — reading tickets, adding internal notes, setting fields, or drafting and sending replies only where you've scoped it to. In practice that means you can let AI triage and comment internally much like a light agent, or authorize it to resolve routine tickets end to end like a full agent, depending on how much autonomy you're comfortable with.

The honest framing: it's another integration to govern, and — like any team member — it only performs as well as the knowledge and rules behind it. On cost, Macha bills per AI action (any automated step — summarize, tag, route, look up data, draft, or resolve — costing 0.5–9 credits depending on the model you pick), not per seat or per closed ticket, because most automation isn't a "resolution," it's work done along the way. If you're mapping out who (and what) should be allowed to act in your account, an AI layer is worth scoping deliberately right alongside your human roles. We walk through it in how to automate Zendesk with AI. You can also try it free — 7-day free trial, no credit card required.

Frequently asked questions

What are the user types in Zendesk? Zendesk splits everyone into two broad user types — end users (your customers, who can only submit and track tickets and comment publicly) and team members (your staff). Team members are then one of several roles: account owner, administrator, agent, light agent, contributor, or a custom role. The account owner is a special team member with exclusive control over billing and the subscription.

What's the difference between an agent and an admin in Zendesk? An agent works tickets — they can view and update the tickets they're allowed to see, reply to customers, add internal notes, and build personal macros and views. An admin can do all of that plus manage account settings, create and edit business rules (triggers, automations, SLAs), build reports, and manage users and groups. Admins can't touch billing — only the account owner can.

Are Zendesk custom roles available on every plan? No. Custom roles are an Enterprise (and Enterprise Plus) feature. On Team, Growth, and Professional plans you assign the predefined roles (agent, admin, and — where included — light agent and contributor). On Enterprise, the standard agent role is replaced by custom agent roles you define, starting from Zendesk's predefined system roles.

Do light agents and contributors cost extra in Zendesk? Generally no. Light agents and contributors are typically free and don't consume a paid agent seat — Suite plans include a large pool of light agents (up to 100 on Professional, 1,000 on Enterprise, 5,000 on Enterprise Plus). They only cost a seat if you upgrade them to a full agent role or give them a paid role in an adjacent product like Chat, Knowledge, or Analytics. Support-only plans access light agents via the Collaboration add-on.

Can a light agent reply to customers? No. A light agent can view tickets in their groups, be CC'd, and add internal (private) comments only — they cannot send public replies, be assigned tickets, or edit ticket properties. If someone needs to reply to customers or own tickets, they need a full agent seat. See what is a Zendesk light agent for the full breakdown.

How do I control who can submit tickets to my Zendesk? In Admin Center > People > Configuration > End users, the "Anybody can submit tickets" setting decides whether anyone (or only added users) can open a request, and "Ask users to register" requires email verification first. You can also set up shared organizations so customers in the same company can see each other's tickets.

The bottom line

Zendesk's permission model is layered but logical: start with the three user types — end users, team members, and the single account owner — then assign team members the role that matches their job. Agents work tickets, admins also configure the account, and light agents and contributors collaborate internally for free without burning a seat. On Enterprise, custom roles let you draw those lines as finely as you like, with least privilege as the guiding principle. Round it out by setting end-user permissions so the right customers can reach you the right way — and, as AI enters the picture, scope your AI agent's access just as deliberately as you scope your team's. Get the model right once and everything downstream — security, consistency, and your bill — falls into place. From here, go deeper on light agents, the ticketing system, and the Agent Workspace.

Roles and permissions verified against Zendesk's official documentation, June 2026. Zendesk updates its product periodically — confirm specifics in your own account before relying on them.