In this article by Cedric Jacob, the author of the book Mastering Zendesk, we will learn about agent roles, groups, organizations, user-tags and how each item can be setup to serve a more advanced Zendesk setup. The reader will be guided through the different use-cases by applying the necessary actions based on the established road map.

When it comes to working with an environment such as Zendesk, which was built to communicate with millions of customers, it is absolutely crucial to understand how we can manage our user accounts and their tickets without losing track of our processes. However, even when working with a smaller customer base, keeping scalability in mind, we should apply the same diligence when it comes to planning our agent roles, groups, organizations, and user tags.

This article will cover the following topics:

• Users / agents / custom agent roles
• Groups
• Organizations
• User tags

(For more resources related to this topic, see here.)

Users/agents

In Zendesk, agents are just like end-users and are classified as users. Both can be located in the same pool of listed accounts. The difference however can be found in the assigned role. The role defines what a user can or cannot do. End-users for example do not posses the necessary rights to log in to the actual helpdesk environment. Easily enough, the role for end-users is called End-user.

In Zendesk, users are also referred to as people. Both are equivalent terms. The same applies to the two terms end-users and customers.

You can easily access the whole list of users by following these two steps:

1. Click on the admin icon (gear symbol) located at the bottom of Zendesk's sidebar.
2. Click on People located under MANAGE within the admin menu:

Unlike for end-users, there are a few different roles that can be assigned to an agent. Out of the box, Zendesk offers the following options:

• Agent/Staff
• Team Leader
• Advisor
• Administrator

While the agent and staff roles come with the necessary permissions in order to solve tickets, the team leader role allows more access to the Zendesk environment.

The advisor role, in contrast, cannot solve any tickets. This role is supposed to enable the user to manage Zendesk's workflows. This entails the ability to create and edit automations, triggers, macros, views, and SLAs.

The admin role includes some additional permissions allowing the user to customize and manage the Zendesk environment.

Note: The number of available roles depends on your Zendesk plan. The ability to create custom roles requires the Enterprise version of Zendesk. If you do not have the option to create custom roles and do not wish to upgrade to the Enterprise plan, you may still want to read on. Other plans still allow you to edit the existing roles.

Custom agent roles

Obviously, we are scratching on the surface here. So let's take a closer look into the roles by creating our own custom agent role.

In order to create your own custom role, simply follow these steps:

1.  Click on the admin icon (gear symbol) located at the bottom of Zendesk's sidebar.
2. Click on People located under MANAGE within the admin menu.
3. Click on role located at the top of the main area (next to "add"):

The process of creating a custom role consists of naming and describing the role followed by defining the permissions:

Permissions are categorized under the following headlines:

• Tickets
• People
• Help Center
• Tools
• Channels
• System

Each category houses options to set individual permissions concerning that one specific topic. Let's examine these categories one by one and decide on each setting for our example role–Tier 1 Agent.

Ticket Permissions

In the first part, we can choose what permissions the agent should receive when it comes to handling tickets:

What kind of tickets can this agent access?

• Those assigned to the agent only
• Those requested by users in this agent's organization
• All those within this agent's group(s)
• All

Agent can assign the ticket to any group?

• Yes
• No

What type of comments can this agent make?

• Private only
• Public and private

Can edit ticket properties?

• Yes
• No

Can delete tickets?

• Yes
• No

Can merge tickets?

• Yes
• No

Can edit ticket tags?

• Yes
• No

People Permissions

The second part allows us to set permissions regarding the agent's ability to manage other users/people:

What access does this agent have to end-user profiles?

• Read only
• Add and edit within their organization
• Add, edit, and delete all

May this user view lists of user profiles?

• Cannot browse or search for users
• Can view all users in your account

Can add or modify groups and organizations?

• Yes
• No

So what kind of access should our agent have to end-user profiles?

For now, we will go for option one and choose Read only. It would make sense to forward more complicated tickets to our "Tier 2" support, who receive the permission to edit end-user profiles.

Should our agent be allowed to view the full list of users?

In some cases, it might be helpful if agents can search for users within the Zendesk system. In this case, we will answer our question with a "yes" and check the box.

Should the agent be allowed to modify groups and organizations?

None of our planned workflows seem to require this permission. We will not check this box and therefore remove another possible source of error.

Help Center Permissions

The third part concerns the Help Center permissions:

• Can manage Help Center?
  • Yes
  • No

Does our agent need the ability to edit the Help Center?

As the primary task of our "Tier 1" agents consists of answering tickets, we will not check this box and leave this permission to our administrators.

Tools Permissions

The fourth part gives us the option to set permissions that allow agents to make use of Zendesk Tools:

What can this agent do with reports?

• Cannot view
• Can view only
• Can view, add, and edit

What can this agent do with views?

• Play views only
• See views only
• Add and edit personal views
• Add and edit personal and group views
• Add and edit personal, group, and global views

What can this agent do with macros?

• Cannot add or edit
• Can add and edit personal macros
• Can add and edit personal and group macros
• Can add and edit personal, group, and global macros

Can access dynamic content?

• Yes
• No

Should our agent have the permission to view, edit, and add reports?

We do not want our agents to interact with Zendesk's reports on any level. We might, instead, want to create custom reports via GoodData, which can be sent out via e-mail to our agents. Therefore, in this case, we choose the option Cannot view.

What should the agent be allowed to do with views?

As we will set up all the necessary views for our agents, we will go for the "See views only" option. If there is a need for private views later on, we can always come back and change this setting retroactively.

What should the "Tier 1" agent be allowed to do when it comes to macros?

In our example, we want to create a very streamlined support. All creation of content should take place at the administrative level and be handled by team leaders. Therefore, we will select the "Cannot add or edit" option.

Should the agent be allowed to access dynamic content?

We will not check this option. The same reasons apply here: content creation will happen at the administrative level.

Channels Permissions

The fifth part allows us to set any permissions related to ticket channels:

• Can manage Facebook pages?
  • Yes
  • No

There is no need for our "Tier 1" agents to receive any of these permissions as they are of an administrative nature.

System Permissions

Last but not least, we can decide on some more global system-related permissions:

1. Can manage business rules?
   • Yes
   • No
2. Can manage channels and extensions?
   • Yes
   • No

Again, there is no need for our "Tier 1" agent to receive these permissions as they are of an administrative nature.

Groups

Groups, unlike organizations, are only meant for agents and each agent must be at least in one group. Groups play a major role when it comes to support workflows and can be used in many different ways. How to use groups becomes apparent when planning your support workflow.

In our case, we have four types of support tickets:

• Tier 1 Support
• Tier 2 Support
• VIP Support
• Internal Support

Each type of ticket is supposed to be answered by specific agents only. In order to achieve this, we can create one group for each type of ticket and later assign these groups to our agents accordingly.

In order to review and edit already existing groups, simply follow these steps:

1. Click on the admin icon (gear symbol) located at the bottom of Zendesk's sidebar.
2. Click on People located under MANAGE within the admin menu.
3. Click on groups located under the search bar within the main area:

Creating a group is easy. We simply choose a name and tick the box next to each agent that we would like to be associated with this group:

There are two ways to add an agent to a group. While you may choose to navigate to the group itself in order to edit it, you can also assign groups to agents within their own user panel.

Organizations

Organizations can be very helpful when managing workflows, though there is no imperative need to associate end-users with an organization. Therefore, we should ask ourselves this: Do we need to use organizations to achieve our desired workflows?

Before we can answer this question, let's take a look at how organizations work in Zendesk:

When creating an organization within Zendesk, you may choose one or more domains associated with that organization. As soon as an end-user creates a ticket using an e-mail address with that specific domain, the user is added to that organization.

There are a few more things you can set within an organization. So let's take a quick look at all the available options.

In order to add a new organization, simply follow these steps:

1. Click on the admin icon (gear symbol) located at the bottom of Zendesk's sidebar.
2. Click on People located under MANAGE within the admin menu.
3. Click on organization located at the top of the main area (next to add):

When adding a new organization, Zendesk asks you to provide the following details:

• The name of the organization
• The associated domains

Once we click on Save, Zendesk automatically opens this organization as a tab and shows next to any ticket associated with the organization. Here are a few more options we can set up:

• Tags
• Domains
• Group
• Users
• Details
• Notes

Tags

Zendesk allows us to define tags, that would automatically be added to each ticket, created by a user within this organization.

Domains

We can add as many associated domains as we need. Each domain should be separated by a single space.

Group

Tickets associated with this organization can be assigned to a group automatically. We can choose any group via a drop-down menu.

Users

We get the following two options to choose from:

• Can view own tickets only
• Can view all org tickets

This allows us to enable users, who are part of this organization, to only view their own tickets or to review all the tickets created by users within this organization. If we choose for users to view all the tickets within their organization, we receive two more options:

• ...but not add comments
• ...and add comments

Details

We may add additional information about the organization such as an address.

Notes

Additionally, we may add notes only visible for agents.

User-Tags

To understand user tags, we need to understand how Zendesk utilizes tags and how they can help us.

Tags can be added for users, organizations, and tickets, while user tags and organization tags will be ultimately applied to tickets when they are created.

For instance, if a user is tagged with the vip tag, all his tickets will subsequently be tagged with the vip tag as well:

We can then use that tag as a condition in our business rules.

But how can we set user tags without having to do some manually?

This is a very important question. In our flowchart, we require the knowledge whether a customer is in fact a VIP user in order for our business rules to escalate the tickets according to our SLA rules. Let's take a quick look at our plan:

• We could send VIP information via Support Form.
• We could use SSO and set the VIP status via a user tag.
• We could set the user tag via API when the subscription is bought.

In our first option, we would try to send a tag from our support form to Zendesk so that the ticket is tagged accordingly.

In our second option, we would set the user tag and subsequently the ticket tag via SSO (Single Sign-On).

In our last option, we would set the user tag via the Zendesk API when a subscription is bought. We remember that a customer of our ExampleComp becomes eligible for VIP service only on having bought a software subscription.

In our case, we might go for option number three. It is a very clean solution and also allows us to remove the user tag when the subscription is canceled.

So how can we achieve this?

Luckily, Zendesk offers a greatly documented and easy to understand API. We can therefore do the necessary research and forward our requirements to our developers. Before we look at any code, we should create a quick outline:

1. User registers on ExampleComp's website: A Zendesk user is created.
2. User subscribes to software package: The user tag is added to the existing Zendesk user.
3. User unsubscribes from software package: The user tag is removed from the existing Zendesk user.
4. User deletes account from ExampleComp's website: The Zendesk user is removed.

All this can easily be achieved with a few lines of code. You may want to refer your developers to the following webpage:

https://developer.zendesk.com/rest_api/docs/core/users

If you have coding experience, here are the necessary code snippets:

For creating a new end-user:

curl -v -u {email_address}:{password} https://{subdomain}.zendesk.com/api/v2/users.json  
-H "Content-Type: application/json" 
-X POST 
-d '{"user": {"name": "FirstName LastName", "email": "[email protected]"}}'

For updating an existing user:

curl -v -u {email_address}:{password} https://{subdomain}.zendesk.com/api/v2/users/{id}.json 
-H "Content-Type: application/json" 
-X PUT 
-d '{"user": {"name": "Roger Wilco II"}}'

Summary

In this article, you learned about Zendesk users, roles, groups, organizations, and user tags. Following up on our road map, we laid important groundwork for a functioning Zendesk environment by setting up some of the basic requirements for more complex workflows.

Resources for Article:

Further resources on this subject:

• Deploying a Zabbix proxy [article]
• Inventorying Servers with PowerShell [article]
• Designing Puppet Architectures [article]