Understanding Zendesk user roles

Zendesk defines a number of user roles that are key to managing the people who generate support requests, those who resolve them, and the tickets themselves.

Users and people are essentially equivalent terms; it's the broadest definition for all people who use your Zendesk. When you need to manage people in your Zendesk, your starting point is almost always the People page. This is where you add new users, define their roles and privileges, and then organize them using groups and organizations. You'll usually only see the word users in documentation like this.

Each user's role is defined when they are added to your Zendesk, although you may change a user's role as needed. And, when users sign in, they are only shown the parts of your Zendesk that they are allowed to see and use.

End-users, or customers

End-users are also sometimes referred to as customers. These are the people who generate support requests from any of the available support channels (Web portal, email, Twitter, etc.). End-users don't have access to any of the administrator and agent features of Zendesk. They can only submit and track tickets and communicate with agents publicly, which means that their ticket comments can never be private.

How end-users interact with your Zendesk depends first on the support channels you've made available to them and then by how you've defined public access. You can run an open or closed Zendesk. Open means that anyone can submit tickets. Closed means the opposite, and as you might imagine, it's how you'd set up your Zendesk for an internal support operation for a corporation, for example. In a closed Zendesk, you add the end-users. In an open Zendesk, you can add users yourself and end-users can add themselves by submitting tickets.

You can either require end-users of an open Zendesk to register, or not. In a closed Zendesk, all end-users must be registered of course.

You can also control if and how your end-users access your Help Center or Web portal. This is the end-user's view of your Zendesk and includes the submit request page, the knowledge base and community, and a view of their tickets. However, if your end-users aren't registered, they don't have access to that view of tickets (they must be logged in). For these end-users, all communication with the support team is via email. For more information, see Setting up to provide email-only support.

You also have the option of adding your end-users to an organization, which is a collection of users (both end-users and agents) that can be used in many ways throughout your ticket workflow. For more information, see About organizations and groups.

Agents, administrators, account owner

The people who resolve support requests, you, play different roles in setting up and managing your ticket workflow.

Agents

Agents are the bulk of the support staff. They are assigned tickets and interact with customers as needed to resolve support issues. The agent's role and privileges are defined by admins and may include the following:

• May be added to more than one group (must be added to at least one)
• Add end-users
• Add public or private comments or both to tickets
• Create and edit their own macros
• Create and edit their own views
• Can view reports
• Moderate and manage articles in the Help Center or Web portal
• Access tickets in one of the following ways:
  • All tickets in your Zendesk account
  • Only tickets assigned to the group or groups to which they belong
  • Only tickets received from the organization to which they belong
  • Only tickets that they are assigned to

On Enterprise, you can define your own agent roles and choose what each role is allowed to see and do in your Zendesk. For more information, see Custom agent roles.

Administrators can add new agents either manually one at a time or as a bulk import operation (you can set the user role in the CSV data file used in a bulk import). Agents can be promoted to the administrator role by an administrator.

Agents are added to groups. Each agent must be added to at least one group. For more information about groups, see About organizations and groups.

As noted above, there are a number of ways to limit the access agents have to tickets. These are explained in Creating, managing, and using groups.

Notwithstanding ticket access restrictions, CC'ing an agent on any ticket lets the agent receive email notifications of all public and private updates to the ticket. For example, suppose an agent is only allowed to see tickets in the L2 group. After the agent is CC'ed on a ticket in the L3 group, the agent gets email notifications of all public or private updates to the ticket even though she's not authorized to see L3 tickets.

Administrators

Admins are agents with additional privileges to manage and customize your Zendesk. Admins can be assigned tickets like agents but they may also do the following:

• Access all tickets (not just the tickets they are assigned to)
• Create new business rules (automations, macros, SLA service targets, triggers, views)
• Access and edit all business rules (automations, macros, SLA service targets, triggers, views)
• Access and edit all extensions (widgets, targets, etc.)
• Create reports
• Edit all reports
• Access settings pages (account, security, channels, etc.)
• Access all forums with moderator privileges
• Add and manage end-users, agents, and admins
• Promote agents to the admin role
• Create groups and organizations
• Assume another user's identity
• Create custom agent roles

Administrators are responsible for designing and implementing the ticket workflow. They add end-users, agents, and other administrators; define the business rules (automations, triggers, views, etc.); and customize and extend your Zendesk. Where an agent's primary function is to interact with end-users and resolve support requests, administrators may do that as well as set up and manage the workflow.

Note: You may find general references in the documentation or the user interface to agents being able to do something in Zendesk. It's important to remember that if an agent can do something so can an administrator. It's not the other way round. So, the shorthand of 'agent' may be used at times when the exact implication is 'agent and administrator'.

Account owner

The account owner is a type of administrator. The account name is associated with this person's name, usually the person who created the account. There can only be one account owner; however, account ownership can be reassigned by the account owner to another administrator if needed. The account owner has access to areas of your Zendesk that other administrators do not, such as invoicing, payment options, and benchmarking for the account.

User references in business rules

Business rules need to refer to some types of users in more abstract ways to define conditions and actions; therefore, you'll see references to requester, submitter, assignee, current user, and non-restricted agent.

Requester

Requester refers to the person who made the support request. Requester is used in macros, views, automations, triggers, and reports to refer to the person who generated the support request.

Submitter

The ticket submitter is either the user who submitted the request or the agent that opened the ticket on behalf of the requester.

Assignee

Assignee is the agent assigned to a ticket. Assignee is used in macros, views, automations, triggers, and reports to refer to or set the assigned agent.

Current user

Current user is a reference to the last person who updated the ticket, which is not necessarily the same person who is assigned to the ticket. The current user (whoever updated the ticket last) changes whenever the ticket is updated. And, the update may have been made by the assignee, the requester, or someone who was CC'd on the ticket.

Non-restricted agent

A non-restricted agent is an agent who has access to all tickets. In other words, they have not been restricted to only the group or groups to which they belong, the organization they belong to, or to the tickets they have been assigned to. The ability to refer to these agents may be useful when creating triggers.