Creating Subgroups to Manage Departments
We have different departments and have different teams in all of them. We need sub groups for each department (Group) in order to manage Chat and Ticketing system. The main purpose is; restricting agents in different groups (Deps) to see each others' tickets.
Actually, we are creating chat groups, different gorups for each department's team. They have to see each others' tickets in the same department for ticket history but should not see other departments' tickets.
Creating sub groups will solve all of the problems.
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.
1. Private groups where only those who are assigned to those groups or admin can view
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.
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?
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.
Alina Wright 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:
- 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.
- Groups can be used to make different sets of Macros available to agents.
- Groups can be used to set which Views an agent have access to.
- Groups can be used to set access to Zendesk Apps.
- 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).
- Groups can be used to group Agents for the purpose of sending email notifications (to the group members).
- 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.
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?
Thanks for this extensive feedback!
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!
Alina Wright is this in the pipeline this year?
Gerald J - 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.
Por favor, entrar para comentar.