Creating Subgroups to Manage Departments

Also, even allowing us to nest agent groups using the :: syntax would be very helpful to organize the group list!

This would be great.  One of the flaws of the Agent Workspace is seeing all the groups in a single hit so not easily being able to see the chat groups versus the ticket groups etc

This would be great. Is there any timeline for such a feature?

Hey all, we have something coming down the line that might of interest to you all. We're calling it "Private Groups" and the idea is fairly straightforward.

You'll have:

1. Private groups where only those who are assigned to those groups or admin can view

or

2. Public groups where anyone who has access to public groups can view tickets without being explicitly added to the group.

I would love to chat with you and see if this fits your use case. Here's my calendly link if you'd like to sync up for 30 minutes and chat through your use cases and if this will fit the bill.

Thanks so much for taking the time to provide this feedback.

Hi Alina, I added a meeting to discuss my Use Case. I would like to see and discuss how your feature could assist with Reporting.

I added more information to this thread. https://support.zendesk.com/hc/en-us/community/posts/4409217529498-Grouping-Groups-Add-Hierarchy-to-groups

Alina, We are in the process of overhauling out groups and desperately need this as we do not want Customer Support to see IT and Accounting departments, but all of customer support needs to see all 17 groups under them. do you have a timeline for this? We are currently working on a horrible work around. thank you! 

Great speaking with you TJ!

Hi Meg! I see we have some time scheduled to chat through this on Monday. We can talk through timelines more concretely then but we're looking at some time mid next year for general release. 

Hi Alina!  Do you have a timeline?  Will this be available for all suites?  We are currently in the process of looking into upgrading from Professional to Enterprise Suite and merging our 3 accounts into one, and this functionality would be greatly needed.

Has there been any progress in this? I would be interested in knowing more since we have so many groups that are not related to each other that it is often quite a scroll to get  to the right group you are looking for. 

It would be cool to "categorize" groups too, much like a ticket field. Payroll::Payroll SE for example. 

Hi all! Yes, we're almost to general availability. Keep an eye out for a release in April or June - pending some performance enhancements. 

@alina12 If you have been working with groups recently, I have a (maybe tangentially) related question relating to another type of group restrictions. Can you take a look?

Premise: Groups are multi-purpose objects in Zendesk

Groups in Zendesk are used to adress many different concerns:

1. Groups can "carry/contain"  tickets, where they then control access, workflows, are indirectly used for reporting, etc. This is the primary use case of Groups. 
2. Groups can be used to make different sets of Macros available to agents. 
3. Groups can be used to set which Views an agent have access to. 
4. Groups can be used to set access to Zendesk Apps.
5. Groups can be used to signal "team/organization" membership (for example if ticket groups from 1 doesn't map 1-1 to actual business organizations).
6. Groups can be used to group Agents for the purpose of sending email notifications (to the group members).
7. Groups can be more generically be used to create a set of arbitrarily related agents (unlike user tags, which can attach to both end-users and agents). This can them be leveraged for various processes, by APIs, etc. 

However, Zendesk doesn't really distinguish between these use cases. 

No properties can be assigned to a Group to tell it should only relate to Views restrictions, i.e. Tickets should not be assignable to the Group. Or that a Group should associated to carry Tickets and grant access to Macros, but nothing else. 

My issues

Here's are some issues I run in to, that I feel all derive from the situation that Groups are multi-purpose objects in Zendesk, but there is no support for that distinction in the Zendesk Support platform right now. 

A) If I create a Group for the purpose sharing a common set of Macros to certain users, those Groups will now be listed a assignable to Tickets.

So I can create a group an aptly name it "Customer Service standard phrases", but the side effect is that now the group is listed in the Assignee field and it's available as a condition and target in business rules (i.e. Automations, Triggers, SLAs, etc).

The fact Zendesk doesn't track which Group can carry tickets, so that my "Group for Macros" now can be assigned Tickets, complicate things. Because now I need to take extra steps to avoid tickets from being listed in the Ticket sidebar interfaces, I need to put triggers or automations in place to ensure tickets mistakenly assigned to Groups which should not carry tickets are redirected somewhere that our views/agents/reports are actually looking for them, they "spam" the business rules conditions and targets. Etc.

B) The use cases 2-7 above all have these side effects. E.g. in use case 4, when I create a Group to assign a Zendesk App to a set of agents, or in use case 5 when I use Groups to collect a set of agents into Teams. 

C) In practice, use case 2 (Groups for "Macros") and 3 (Groups "for Views") is probably my biggest pain point right now.

For use case 3 (views) I often decouple my Groups "for Views" from my Groups "for Tickets", for several reasons which I won't list here,  since I'm sure you're already familiar with many of them. For my use case 2 (macros) it's a similar concern, but of relatively less importance to me.  

My current workarounds

The ways I address the issues relating to my use cases 2-7 today include:

I.) A custom Zendesk app that hides the Groups from showing in the Ticket assign field

Ia.) However this is not possible for the Edit Tickets (Bulk) interface AFAIK.

Ib.) Similarly this doesn't prevent especially triggers and macros from listing the Group.

II.) Naming conventions. I try to hint how to use (or not use) the Group by its name. E.g. "Common Customer Service Views", "Manager views", etc.

IIa.) It doesn't work super great, and some cases are not so clear-cut.

Some Group names becomes a a bit too verbose (and the interace doesn't love long Group names), and sometimes a title is truncated in the interface, and sometimes users are just not that observant.

We have many groups, so when a "select group" dropdown appear, its often a search bar, and my experience is that my agents or admins mistakenly selects wrong.

As proven by my catch-bad groups triggers, that regularly fire to reassign tickets assigned to Groups with "Views" in their name, and similarly for selecting macros. 

III.) Agent education. But I'd argue the system design should make it "easy to do right". If the Ticket interface or macro or views etc list a group as assignable to it, they should be able to assume the groups listed there are all valid selections. 

IIIa.) Based on how often I have to adjust macros set to ticket groups instead of macro groups (even though Macro is in the name), despite education, and considering the cost of agent education (Zendesk is already our agent-education most intensive system because of it's "open design"), addressing this with agent education is a not a great solution for me. 

VI.) Business rules. I try to have triggers in place that automatically tracks assignments to Groups that shouldn't carry tickets, ever.

If the triggers are not in place, some tickets inevitably ends up in Groups not meant to carry tickets, which then often results in they being effectively lost ("ball dropped"), as well as they might become Closed and then messes up reporting for all future, since by the time we find the ticket, their group can no longer be "corrected" since ticket is frozen. 

My product feature requests

My most important product features request relating to this problem space and my use cases 2-7 would be something like below, with my highest priority being the first request.  

Feature request 1) That I can designate if a Group can be assigned Tickets or not.

If a Group cannot be assigned tickets, the Group should not be listed in the areas of the Zendesk  product that deals with Ticket Groups, i.e. assignee input dialogs, bulk edit dialog, triggers, SLAs, etc.

This feature would add great value to all my use cases 2-7, and I would be able to significanly simplify my Zendesk setup, and decrease on my agent education. 

Feature request 2) I can distinguish what objects a Group can relate to in more detail.

This would add the greatest value for my use case 2-4.

If I could assign whether a Group is related to one or more of Macros, Views, or Apps (etc).

Then if I am on the Macro page and select to restrict the macro by groups so I get the "group picker", I would expect to only see entries that are Groups that are "macro-related". 

I'd suppose some backwards-compability, like listing include all (legacy) Groups that have no relationships set yet, might be in place.

Or it doesn't have to be "Groups" that adds this functionality. If a new concept that is not related restricting access to Tickets, but rather to group and restrict access to business objects like Views, Marcos, etc,  that would be totally fine by me. Either way, I expect that I would need to update my config to get the benefit of the new functionality. 

That's my feature requests. Sorry for the wall of text :)

Is this perhaps something you or another PM are already looking to deliver this year 2022?

I really need group nesting as well, the :: syntax as is used with macros would be great. I have 66 groups and counting and most could be nested as sub-topic groups. First select high level group of subject matter category, next level is individual sub-topic groups. For now I am using prefixes to have them all appear in alphabetical order together for a given topic.

We also really need nesting of groups 

Joel's comment really hits our use cases of needing to be able to nest ticket groups. The access to views while not wanting agents to assign tickets to the group is a frustrating painpoint.

I'm really keen to see nested groups too - we have multiple teams working together sometimes on similar activities and having to have a ticket assigned to a specific group doesn't' make sense. Adding agents to multiple groups also makes assignment messy. 

Upvote for this - need to be able to nest groups!

@alina12 is this in the pipeline this year?

@gerald11 - Hey there, nested groups are not currently something that is prioritized for 2023. We are working on better supporting multiple department / business unit use cases however, so I'm hoping we can make some significant movement there.

This would be a great option. Right now we have different teams/departments in Zendesk, and we also have a group of users from our company that need to access tickets only as light agents. In order for them to see tickets from different groups , i have to give light agents access to view tickets from all groups, not just lets say developers can view tickets created by customers and are assigned to level1 or level2 customer support. But they dont need to see operations tickets. If i can group IT (level1, level2, security etc) into one group (support) and let developers see only those support tickets, that would be great

Up vote for this too extremally needed . 

Hi all, we are not working on nested groups for 2024. We continue to prioritize Brand Space and restricting access to brands via membership. An EAP is planned with details below:

What is the Early Access Program?

The Early Access Program is designed to provide our customers with early access to new features and improvements. By participating in the EAP, you will have the chance to explore these enhancements ahead of their official release and provide valuable feedback that will help shape the final product.

What is Brand Based Ticket Access EAP?

"Brand-based ticket access" in Zendesk allows agents to manage tickets associated only with their assigned brands. This ensures focused support, enhances data privacy, and promotes specialized product knowledge. Agents will now belong to brands and their ticket access will depend on their brand membership. Zendesk Admins will automatically belong to all brands.

How to Enroll

Enrolling in the EAP is simple. Just click on the following link: Sign Up for EAP and follow the instructions to register. Once you've signed up, you'll receive further information on how to access and use the new features. We are planning to launch in Q1 2024 and will follow up prior to any activation. Filling out the Sign Up form does NOT automatically enroll you in the EAP.

A few weeks prior to the release of Brand Based Ticket Access EAP, I will email you with instructions, screenshots, and a specific timeline. 

Expectations of Participants

As a participant in the EAP, we kindly ask for your active engagement and feedback. This may include participating in surveys, providing feedback on your experience, and reporting any issues you encounter. Your insights and suggestions will be invaluable in helping us refine our products and ensure they meet the needs of all our customers.

If you have any questions or need further clarification, please don't hesitate to reach out to me directly at alina.wright@zendesk.com. We greatly value your input and look forward to your participation in our Early Access Program.

Thanks,

Alina Wright

Thanks @alina12 the Brand solution will work for some scenarios, but not mine, it has too many undesired consequences. 

I desperately need the nested groups feature. 
We have a huge number of light agents, and it's incredibly difficult to ensure that the right people see the right tickets when they log in (without getting their emails flooded with irrelevant notifications).

I just need to be able to link to a single “parent” group. 
Permissions wouldn't really change too much. If they are a member of the group they receive email notifications (Members of child groups are considered members of a parent group) 

For example, a structure like this.
Executive Group > Senior Leadership Group> Middle Managers> Team Leaders>Supervisors>Front Line Subject Matter Experts. 

If a ticket gets assigned to the "front line subject matter experts" the members would all receive a notification and be able to see the tickets when they log in. 

Anyone who is a member of a group further up the hierarchy can also see the tickets if they log in, but they do not receive any notifications. 

If a ticket is assigned to the "Team Leaders" group, the supervisors and front-line subject matter experts will not be able to see it, and only those in the supervisors group will receive a notification. Anyone in the higher levels, such as Executives, will be able to see the tickets assigned to any group below them in the hierarchy.

I have 400+ subject matter experts and currently none of their leaders can see what is happening with their tickets. leaving the follow-up of overdue responses to my team of 20 agents, not fair on them!