Zendesk Groups
Zendesk groups are a collection of agents. That's the entire concept. Nearly every routing problem in Zendesk traces back to somebody expecting more.
Groups, organizations and brands
Three words that get used interchangeably in meetings and mean completely different things in the product.
The trap is assuming these line up one to one. They usually do not. You might have one group serving four brands, or three groups serving a single organization. Model each one for what it is and the routing gets much simpler.
Zendesk groups: membership and the default
Every agent belongs to at least one group. On plans that allow it an agent can belong to several, with one marked as their default, which is the group a ticket lands in when that agent creates one and the group their personal queue defaults to. Multiple group membership is plan dependent, so check what your tier includes before designing around it.
Two membership patterns, and they behave very differently. Narrow membership, where each agent sits in one group, gives clean reporting and clean queues but leaves you exposed when somebody's off. Broad membership, where most agents sit in most groups, gives resilience and a sidebar full of queues nobody feels responsible for.
The middle path that usually works: everyone has a home group, and a smaller set of senior agents sit in several so escalation has somewhere to go.
What groups actually control
More than people realise, which is why creating one casually has consequences.
That last point is worth dwelling on. If you cannot slice your numbers the way you want, the cause is often a group model that grew by accident.
Routing to a group
Three routes, in ascending order of how much thought they need.
A trigger sets the group on create, based on form, tag, brand, keyword or organization. This handles the vast majority of routing and it is the one to build first. Keep the conditions readable, because a trigger list that only its author understands is a liability.
A macro sets the group when an agent hands work over. Pair it with an internal note template so the receiving team gets context rather than a bare reassignment.
Skills-based or omnichannel routing distributes within a group, which is a different problem from getting the ticket to the right group in the first place. Worth reading on omnichannel routing and round robin if that is what you are really after.
How many groups is too many
The honest test: can you name every group and say who owns it, out loud, without checking? If not, you have too many.
Groups multiply because creating one is easy and deleting one is not. Somebody sets up a group for a project, the project ends, the group remains, and eighteen months later a trigger routes something into it and the ticket sits unread for a week.
Before creating a group, ask whether a tag would do. If the only reason is reporting, use a tag or a custom field. If the reason is that a different set of humans works these tickets on a different clock with different permissions, that's a group and you should make it.
Deactivate the ones you retire rather than deleting, and check first that no trigger, view or SLA policy still points at them. A trigger routing to a deleted group is a genuinely miserable thing to debug.
Frequently asked questions
How does Zendesk group routing actually work?
A trigger sets the group, and the group's members see the ticket in their views. Zendesk group routing is the only routing most teams need, and assigning to a person on top of it is what creates the tickets nobody picks up.
What is the difference between a Zendesk group and an organization?
A group contains your agents. An organization contains your end users, usually a customer company. They are unrelated objects that happen to sit in similar places in the admin interface.
Can a Zendesk agent be in more than one group?
On plans that support it, yes, with one marked as the default. Availability varies by tier, so check the current Zendesk docs for your plan.
What happens to tickets if I delete a group?
Check every trigger, view, macro and SLA policy that references it first, then deactivate rather than delete where you can. Orphaned references are hard to spot afterwards.
Should I create a group or use a tag?
A group when a genuinely different set of agents works the tickets, with different hours or permissions. A tag when you only need to categorise or report.
Do groups affect SLA policies?
They can. Group is available as an SLA condition and schedules can be applied by group, so a team working different hours can get a different clock.
Two groups, one customer, two tickets
Split teams are the most reliable duplicate generator there is. Ticket Merger spots the pair whichever group each landed in.
Start free trial14-day free trial. No credit card required.