Organizations and groups are used to manage your Zendesk Support users and the ticket handling workflow.
This article discusses the following topics:
Organizations and groups, defined
Each collection of users is defined as follows:
Organizations are typically collections of your end users, but they can also include team members. On the Team plan, users can belong to only one organization. On Professional and Enterprise plans, users can belong to up to 300 organizations. The use of organizations is optional, but by arranging your end users into organizations you can keep track of what those organizations are requesting. You can also enable users within an organization to see each other’s tickets. This expands visibility of the organization's support issues and should reduce the number of duplicate tickets.
Groups collect team members together based on criteria those team members have in common. Groups can only contain team members; no end users can be included. All agents must be assigned to at least one group, but they can be members of more than one. Groups can be used to support organizations. You can designate one group as the default group for your account and you can also designate a default group for each team member. All new team members you create will be added to the default group.
End users and organizations
Although you don't have to add your end users to organizations, it can be extremely helpful in managing the workflow. First, let's define that we mean by end user. These are the people that generate support requests. They are your customers in a retail setting and the employees that are supported by an internal help desk in a corporate setting (to name two common types of end users). How you organize your end users is entirely up to you; however, here are a few examples of how organizations can be used:
To support service level agreements
You can create organizations that mirror the service level agreements that you've established with your customers. For example, your paying customers are guaranteed a faster response than those who use your free services and you want to distinguish between the two. Or, perhaps you've set up levels of support based on which version of your products and service levels your customers have purchased (for example: basic, professional, enterprise or silver, gold, platinum). You can create organizations for each set of customers and route them through the support workflow accordingly. You can then create business rules and reports to escalate tickets as needed and to track performance against your service level agreements.
To track and manage tickets by company
Perhaps you sell your products to other businesses. You can create organizations for each of those companies to manage and track their ticket activity.
To manage requests based on email domains
You can automatically add end users to organizations based on their email domain. For example, you might have both internal and external end users. You can create an organization for your internal end users and automatically add them to the organization, based on their email domain, the first time they submit a request. The new request is then picked up in the workflow rules you've set up for that organization.Note: When you add a domain to an organization, that domain is handled as if it has been added to your allowlist, and overrides the blocklist. For more information, see Using the allowlist and blocklist to control access to Zendesk Support.
To support customers by location and language
If you support organizations or individual customers across the globe, you can create organizations for locations and languages and then route those requests to agents that are co-located and speak the same languages.
To define access to Help Center
You can use organizations to create user segments to define who can see what in your Help Center. You might want most of your Help Center to be viewable by all end users but also create several just for certain groups of users (customers with premium service plans, perhaps). Organizations enable you to do this. For information see Creating users segments for Guide user permissions.
You can create organizations and add end users to them manually, one at a time, or automate the process by adding users and their organizations in bulk import operations.
Team members can also be added to an organization. You might do this as part of organizing the users in Zendesk Support or to restrict an agent's access to only the organization they belong to (this is an option when setting the agent's privileges).
Once you've gotten organizations set up, they can be used in many ways in Zendesk Support to manage your workflow. See How to use your organizations and groups below.
Agents and groups
Groups are only for team members and every agent must belong to at least one group. Like organizations, how you set up groups depends on your business needs and the support workflow you prefer. Here are some of the common ways that groups are used:
To escalate tickets based on complexity
You can manage escalation by setting up a tiered support group structure. For example, you can create groups for levels of support based on factors such as urgency and complexity. By default, you could assign all tickets to the Level 1 group and then escalate them to Level 2 manually based on the technical complexity of the issue. The Level 2 agents (who may also be members of the Level 1 group) have the advanced technical skills needed to resolve the issue. For an example of this, see Managing your escalation queue.
To support service level agreements
As in the example for organizations above, you can set up corresponding groups to support organizations defined by service levels.
To provide support by expertise
You can create groups based on expertise. For example, a company that develops both software and hardware might place the team members who support the software into one group and those team members who support the hardware in another. A custom field could be added to the support request form prompting end users to specify the product they're seeking support for and this could be used to route the ticket to the appropriate group.
To support customers by location and language
As noted above, you can set up organizations by location and language and then assign team members (or groups) to their tickets. Even if you didn't set up organizations for this, you can route to tickets to these groups based on the end user's email domain (somecompany.fr, for example) or their language preference.
To keep sensitive tickets private (Enterprise only)
If you have tickets that contain sensitive or protected information, such as personally identifiable information or security issues, you can create private groups. Only admins and agents in the private group can see tickets assigned to the group. Collaborators and followers, if added to a private ticket, can see all comments, but will not be able to see other tickets within the group. Private groups cannot be converted to public. See About private ticket groups and how they work.
When you create groups, you can add existing team members to them. You can add new team members to one or more groups when you're adding them to Zendesk Support. You can also bulk import new users and define their role as agent, then manually add them to groups.
How groups support organizations
So how do groups support organizations? In the broadest sense, simply by becoming hubs of support for the tickets that are received from the end users in your organizations. What group is assigned to an organization's tickets can be based on the many considerations outlined above (support escalation processes, security, co-location and language, and so on).
You can take a loose approach to this and just allow team members to triage and assign requests to groups based on their reading of the support request or you can create business rules to handle that automatically. See How to use your organizations and groups below.
You can also more tightly manage the workflow and create security boundaries by funneling tickets directly to agents who have restricted access. This means that they can only see the tickets that they are allowed to see. You can do this in two ways. The first is to add the agents to groups and then restrict their access to only those groups. You can also add an agent to an organization, which restricts their access to only those tickets that are submitted by end users in that organization.
How to use your organizations and groups
Once you've got an organization and group structure in place, you can use it to manage the ticket workflow and monitor your Zendesk Support activity.
- Automatically assign tickets received from users in an organization to a specific group, referred to as group mapping (see Mapping a group to an organization).
- Map incoming new users to an organization based on their email domain, referred to as user mapping.
- Allow users within an organization to see all the tickets in their organization, referred to as a shared organization (see Setting up a shared organization for end users).
- Assign team members to support a specific organization (see Adding users to organizations).
- Use organization as a condition in a trigger to automatically assign requests to a group or team member (see Building trigger condition statements).
- Use a trigger condition to test for tags and then automatically assign requests to a group or team member based on those tags (see Creating triggers for ticket updates and notifications).
- Create macros that assign new requests to a group or team member (see Using macros to update tickets).
- Create automations that escalate tickets to a group or team member (see Creating and managing automations for time-based events).
- Create views by organizations or groups (see Creating views by organization).
- Create reports by organizations or groups (see Explore resources).
Administrator and agent roles for users, groups, and organizations
Here's a quick overview of who can do what in Zendesk to manage users, groups, and organizations.
- Add end users manually (one at a time) or add many end users at a time in a bulk import
- Create and edit organizations and groups
- Add end users to organizations
- Create new team members and add them to one or more groups and one organization
- Limit an agent's access to one or more groups
- Limit an agent's access to requests received from the organization that an agent belongs to
- Set up email mapping (automatically map end users from specific email domains to an organization)
- Set up group mapping (assigning incoming requests from users in an organization to a specific group)
- Set up a shared organization (allow all end users in an organization to view tickets from all users in the same organization)
- Create both shared and personal views by users, groups, and organizations
- Create business rules (automations, macros, and triggers) that include groups
- Create business rules (automations and triggers) that include organizations
- Create reports that include groups and organizations
- Add end users
- Add end users to organizations
- Allow end users to view all the tickets in their organization (if the user belongs to a shared organization, then the user always has access to tickets in the organization)
- Create personal views by users, groups, and organizations
- Create macros to assign tickets to a group
@... I'm evaluating Zendesk as an Internal Help Desk. My team of 9 handles queries from 25+ departments, with 9000+ employees. Our customers or end-users are all internal employees with a single domain name
How can we organise the tickets that come in, and recognise which department the ticket is from? We will only have one Group of agents (my team).
How can I ensure that tickets from a single department (eg. Sales) are grouped together, so I can view the historical tickets in the future and not lose context?
You have a couple of options that will help with grouping your tickets:
1. Set up a separate support address for each of department you support in your Zendesk account. This would allow for you to create multiple views based on the support address the ticket is originating from. I've attached a sample view for you below from my test account:
2. Your other option would be to create multiple ticket forms so each of your departments has a ticket form they can submit requests through. This would give you more control over what information is provided to your agents once the ticket has been submitted which can help reduce the back and forth between customer and agent.
Once these forms are created, your internal users can access them from your Help Center new request page. The URL will be https://(your subdomain).zendesk.com/hc/en-us/requests/new or they can select the Submit a Request button towards the top right of your Help Center. I've attached a screenshot of what this would look like once you have multiple forms set up:
Once that's all taken care of, you can create a view for each of your departments based on the Ticket Form the request came in from. Similar to the screenshot I shared above but instead you'll use the Ticket Form condition.
The two above options will be the easiest method for grouping your tickets by department but if that's not quite what you're looking for please let me know.
There's a "hidden trigger" from Zendesk that is not presented yet in this article:
If there is only one agent in a group -> every ticket assigned to this group is automatically assigned to the agent. (even if you have 10 groups)
Is there a way to stop this please :)?
This behavior is expected whenever a group has only one member. I have tried to use triggers and automations to remove it. However, it will not fire as long as the group only has one user.
I'm new to Zendesk, and I'm trying to understand what would be the best way to organize tickets we receive from end-users of two different apps.
Here's what I need:
1. Separate Help Centres for two groups of end-users where
Group 1 using app A has access to app A Help Centre while Group 2 using app B has access to app B Help Centre.
2. Two sets of templates, one per end-user group.
Currently, I have over 100 templates, the list is long and it's not easy to navigate.
I'd prefer 50+ for Group 1 using app A and 50+ for Group 2 using app B.
3. All of the other settings and triggers could be the same for both groups.
Multiple Help centers are supported on Zendesk Suite: Growth and above or a combination of Support and Guide: Enterprise.
You can also have one Help Center, but with articles restricted to a specific user segment. This way, only specified users can access those articles. More information can be found on Can I restrict access to articles?
I am trying to create a view using the "Ticket Form" condition mentioned by Brett but I am having some difficulties locating this. Is it limited to a certain level of subscription?
Yes, creating multiple ticket forms per Brett's suggestion above requires either the Zendesk Suite at the Growth plan level or above, or Zendesk Support Enterprise. There's a graphic at the top of our Help Center articles that shows which plans the given feature applies too (see create multiple ticket forms) for creating multiple ticket forms.
If upgrading your subscription isn't an option, then Brett's first suggestion should still be possible.
Hello, I'm looking to understand the impact of removing users from organizations. Currently, all of our internal users (light agents) are in the same org as our support team (team leaders - the true ticket-resolving agents). I want to be able to put all of our internal clients into the same org and eventually demote them to end-users so that they'll only be able to see tickets submitted by members of their same org/team. If I change their organization now from say A to B, will they still be able to view tickets that were submitted by their team members from when they were still in org A? Thanks
If you change a user's Organization membership from A to B, assuming both are shared organizations, that user will no longer be able to see tickets from other users in organization A.
Hi Dave, that doesn't quite answer my question but I'm assuming the answer is "yes." In other words, it doesn't matter what organization someone belonged to at the time the ticket was opened - if you're in that same person's organization today, you'll be able to see any ticket they've ever opened. Essentially tickets are not forever tied to organizations but they are to users. As long as I put everyone together in the same org, they'll be able to see each other's tickets regardless of what organization they were in at the time the ticket was created - tickets follow the users. Am I making any sense/is that correct?
To clarify: if you're the requester on a ticket, you'll be able to see it no matter your organizations memberships. If you're not the requester or a CC on a ticket, you won't be able to see it unless you're a member of the organization associated with the ticket's requester, and the organization is set to allow shared tickets. Does that answer your question?
Hi Dave, I just did a quick test actually to see what would happen and these were my findings that others may or may not find helpful... The accounts for users A and B were originally created with a default org of X. I created a new org, org Y, and added both users A and B. I deleted org X just from user B's account and made Y the new default. When I asked user B if she could still see a ticket that had been created by user A, even though they are both in org Y, she was not able to see the ticket. I assume this means that tickets are tied to organizations. Just because users share organizations doesn't mean they will have access to ALL of each other's tickets. I'm trying to find a way around this but I realize it's complex so I'm going to follow up with our account rep. Thanks for your help!
Hi, I am trying to set up Zendesk, but having a hard time getting an overview picture of the organisation of the software (and the multiplication of articles and link to articles doesn't help).
- is there a schematic of the steps by step setup:
- Is there a schematic that represents groups, organizations agents etc somewhere?
We are providing support both internally (sales team, R&D team etc) and externally on multiple topics (hardware, software, consumables, consulting etc). Some of the customers have service agreemetns at different levels; we also deal with distributors ...
My reading of this is that the base level is the organisation:
- Service level: eg warranty, SL1, SL2, SL3 (with different rates of response)
- internal requests
- distributor requests
and then within those organisations, have groups
- feature requests etc
thanks in advance
Hi Debora Olivier
An organization is a collection of end-users so just by itself it doesn't have its own SLA. But you can set it up that all tickets from that organization be associated with an SLA by setting up an SLA policy. We understand that searching through multiple articles is a bit taxing. We do offer free Zendesk training here if you are interested to check it out. Hopefully, this helps!
We're setting up new organizations but we need layers of different organizations and organizational units underneath to be able to handle support and also reporting. I can't find how to do it? What can I do to solve this?
Thanks in advance
Hi Anders Bjurdalen,
One of our Community Moderators actually created a workflow that you can try out. It's located here in the similar Community Post called "Sub-Organizations layer and end-user grouping". Hope this helps!
Please sign in to leave a comment.