With Zendesk Support's Multibrand solution, all agents can access tickets for all brands. This enables your support team to seamlessly move between requests from all of your brands and provide faster support.
However, some teams might want to restrict the agents that are able to work on tickets for specific brands. This tip will walk you through that setup.
You can still use group permissions to control the tickets your agents can access. Agents won't be restricted by brand, but with simple routing rules you can get the right tickets to the right people, and prevent others from working on them.
Step 1: Limit agents to groups
Your custom roles can be set to restrict agents to only access tickets within their groups.
To change this setting, go to Admin >Manage > People > Roles and click Edit to the right of the agent's role.
Step 2: Set up all the necessary groups
You need to add groups, then add your agents to these groups. Possibly just one per brand, or maybe many per brand, depending on how granular you want restrictions to be. For example:
- Simple: BrandA, BrandB, BrandC, etc
- Complex: Support_BrandA, Returns_BrandA, Support_BrandB, Returns_BrandB, Support_BrandC, Returns_BrandC, etc
To add groups, go to Admin > Manage > People and click Group in the upper right of the page:
Step 3: Create routing rules
You can now build triggers to route new tickets to a group for the right brand. It might be beneficial to first route tickets to a triage group, who will then assign them to the appropriate group based on the type of request.
Set the condition of the trigger to be when a ticket is created for a certain Brand:
Then the action will assign it to the correct group, and you can add any notification messages or other ticket updates as well:
Optional: Add group-limited views
In addition to the group and trigger workflow, you can also restrict your views to a specific group. This way, you can have a view for BrandA's tickets and only allow a specific group of agents to see that view:
For more information, see Using views to sort branded tickets .
19 Comments
Sorry, if I do that then the agents cant see tickets in other groups that I need them to be able to search on. basically I need Netential agents to see all tickets that are not in their group EXCEPT a specifically named Group. It is to time consuming to have lists of organisations for every consultant. So want I wanted was a way of excluding 1 group
As I understand this means that you cannot follow a ticket that's assigned to another Brand, right?
Basically I need to be able to follow some tickets but not be able so see tickets created from other departments (if I don't have the permission to do that). Is it possible to configure that?
Thanks!
Emelie - It's possible to access tickets from outside your groups if you're CC'd on them. If the assignee can add you as a CC on the tickets you need to follow you shouldn't have any trouble.
Cheers!
When you have Support department with groups Tier1-3, you need that every group will handle their cases and access permission for other Tier group, also you have another department let's say Sales and it has to be hidden from support department. How you would handle this case?
Hey Mindaugas!
You should be able to set up a Sales agent group so that only agents in that group will be able to see their tickets: Creating, managing, and using groups.
It won't hide Sales from other departments.
Can you show me exactly what you have set up? It's hard to know how to help without being able to see what you're working with. Some screenshots would be very helpful.
Tier1-Tier2-Tier3 groups should have shared tickets between each of them but nothing outside these groups. Same for other groups. Sales department groups should access their tickets but not support and so on.
Hi Mindaugas-
This Tip is showing how to use triggers to assign an agent group to a ticket based on the brand of the ticket; from what I am gather this may not perfectly fit your workflow.
It sounds like you're looking to have multiple agent groups have access to all tickets in one brand; so a 1 brand - to- multiple agent groups workflow.
Once tickets are assigned to a group they are inaccessible to all other agents who do not have access to tickets in that group. This in independent of brands. A major factor at play here is brands follow tickets not users.
Therefore assigning brands to agent groups is not something that is currently possible in Zendesk.
If you would like agents in Tier 1,2,3 to have access to the same tickets each agent in Tier 1,2,3 would need to be added to the agent group for Tier 1, 2, & 3.
Can this be built into the role? That would be much easier.
Hi,
This still doesn't prevent agents from viewing other organizations and users from other departments. They can still view all the users and organizations. Is there a way to prevent searches for specific agent groups?
@Rebecca, our use case is similar to Mindaugas Verkys and would LOVE it if it can be considered. As you summarized:
^^This!
We don't want to add agents to multiple groups that they shouldn't belong to just to ensure they have access to a certain set of tickets. That causes so many unintended consequences (group assigned emails, taking a ticket in the wrong group, reporting affects, views would be bloated by nonrelevant tickets, etc).
Any chance this is on the roadmap?
Hi Heather!
As far as I know, this isn't something that we're considering at the moment, and I wasn't able to find anything on it in our Product Feedback forum. It's an interesting idea, though, so I think it would be a good idea to post your suggestion over there to make sure our Product Managers see it.
They might not be able to respond, but they'll definitely see it. Just make sure that you include as much detail about your use case and workflows as possible so they can fully understand the scope of the problem you're trying to solve!
Hi Valentina,
The only way to control the users an agent has access to is to create a custom role for them, and set their permissions there. This feature is available in our Enterprise plans, if you're interested:
Creating custom roles and assigning agents (Enterprise)
If you are not on the Enterprise plan, you can still customize your agents access to tickets, but you are not able to customize their access to your users.
I understand Brands and how it can be useful. However; judging by the comments, this solution falls short of what we really need.
Correct me of I'm wrong but currently, the only way to restrict visibility of tickets for Agents is via Role - it really has nothing to do with Brands.
A Role has 4 options for ticket visibility:
1. Assigned to this agent only
2. Requested by users in this agent's organization
3. All within this agent's group(s)
4. All
The 3rd option is not helpful when you have multiple Groups in a single Brand, and you need every Agent in the same Brand to have visibility to all tickets within that Brand.
It would be extremely helpful if there was an 5th option to allow agents to view tickets by Brand.
Your thoughts...
Agree with @Mjaman.
@Dennis Lynn - even with custom roles, Agents from one Group (aligned with a specific brand) can still create tickets in another Brand, even if the Triggers/Automations/Rules prevent them from seeing those tickets once created.
Restricting agent access strictly to a single brand (to both view & create tickets) would work very well for our SaaS environment. First level support can be provided to the end user by the client support team from within their brand; issues can be escalated to our own (non-brand specific) agents when required. Our agents have access to tickets from all brands, but their responses are branded as per the ticket brand.
This limitation, combined with the inability to share Help Center/Guide content between brands, really negates any value the Multibrand feature could provide.
FYI, especially @Mjaman and @Paul Middleton, I've added a product feedback post at https://support.zendesk.com/hc/en-us/community/posts/360004381167-Restricting-tickets-visibility-to-Brand
Any movement on this to restrict it by role?
Hello Josh,
At this time, we have no announcement or changes to announce on this feature. I would recommend sharing your use case in our product feedback forums so our developers can consider implementing changes for future product updates.
Best regards.
Please sign in to leave a comment.