Administrators have the ability to prevent certain agents from seeing tickets in other groups or tickets that aren't assigned to them (see Agent group permissions and searching tickets). This type of restriction can be incredibly valuable as it limits exposure of sensitive data sent by your customers to those that don't have a need to see it.
This type of restriction impacts an agent's ability to search for tickets and also prevents them from assigning a ticket to an agent outside of their groups, unless an agent is assigned to a role that allows these agents to assign tickets to any group (see Creating custom roles and assigning agents). For example, if your agents use a macro that has an action to assign a ticket to a different group, restricted agents see that the macro appears to not actually reassign the ticket.
To work around restricted agent permissions, you can use triggers and automations to take action on these tickets. Triggers and automations fire on a ticket regardless of the assignee's permissions or role, so combining a custom ticket field (such as a check box or a drop-down field) with a trigger allows your restricted agents to effectively assign tickets as needed.
This article contains the following sections:
- Creating a custom ticket field for group assignment
- Creating a trigger to assign tickets to other groups
- Using this setup to escalate a ticket
Step 1: Creating a custom ticket field for group assignment
In this example, we've created a custom drop-down field called "Escalate to:".
To add the custom field
-
In Admin Center, click the Objects and rules icon (
) in the sidebar, then select Tickets > Fields.
- Click Add field and select Drop-down.
- Add a Display name, the name shown to agents.
- Add the different groups under Field Values as per the picture below.
- Click Save.
Step 2: Creating a trigger to assign tickets to other groups
Next, we need to create three triggers—one for each of the destination groups. These triggers are designed to fire when the ticket is updated, and also remove the value of the custom "Escalate to:" field. This type of configuration ensures the trigger doesn't attempt to fire again on future updates, unless a new group needs to be assigned.
To create the trigger
-
In Admin Center, click the Objects and rules icon (
) in the sidebar, then select Business rules > Triggers.
- Click Add trigger.
- Click the Add condition button under Meet ALL of the following conditions add:
- Ticket Is Updated
- Escalate to: Is Tier 2
- Under Actions add:
- Group Tier 2
- Escalate: -
Using this setup to escalate a ticket
Once you have set up the custom field and triggers, a restricted agent can use the setup to escalate a ticket. The GIF below shows how a restricted agent escalates the ticket.
To escalate a ticket
- Open the ticket that needs to be escalated.
- Change the Escalate to: field to the respective Group ("Tier 2" in the example).
- Click the Submit as button.
When the ticket updates, this restricted agent no longer has access to the ticket, as it is now in a group outside its assigned groups.
11 comments
Omair Ahmed
Oh Wow - it's a lovely thing to have; thanks for creating an article .... additionally, it would've been even better if there's an if-else option here in a single trigger.
e.g. if Escalate to field is Tier-2 then assign to Tier-2 group
or if Escalate to field is Tier-3 then assign to Tier-3 group.
I have 10 different groups and have restrictions for everyone, and I have to create 10 triggers which'll only create noise in my triggers section (though I'm fully using the categories) but still it'll be a good addition. (not sure it's already there! )
0
SYNETIQ Limited
How do we get this to work with Chat?
1
Jason Schaeffer
The tickets crested via Chat would follow the same pattern as the support tickets and the workaround would work for those as well. If you are referring to transferring a live chat as it occurs you can follow the below steps:
Transferring Chats
I hope that helps!
0
Marsy
Can we change the word error or leave it blank with just the verbiage notification? The word error indicates something was done incorrectly
0
Jason Schaeffer
Can you advise in what context you mean regarding the error message? Is this when an agent is attempting to view a ticket outside of their group?
Thanks!
0
Marsy
Hello Jason,
If I restrict an agent to view tickets within their group, they are unable to reassign a ticket to a group they are not part of. While I do not want them to view the ticket after it has been reassigned, I want them to be able to reassign to groups they are not part of.
0
Jason Schaeffer
Unfortunately those permissions work hand in hand. So the only workaround would be using a custom field in conjunction with a Trigger as outlined in the steps above to get the ticket reassigned to the correct group.
Thanks!
0
Antal Clavel
so, I've followed step 1 and step 2 to the letter, but it is not working for me. How can I validate which condition is not met?
0
Dane
In order to investigate further, I'll create a ticket for you. Please wait for my update via email and let's continue our conversation there.
0
Denver CB
Hi everyone,
This is quite useful, thank you. I just wanted to understand better how this solution behaves:
1. If I am part of Group A, and I have a ticket 123 for which I need someone from Group B to do something first before I can complete ticket 123, I create child ticket 456, which will then get assigned to Group B via the trigger.
2. I need to know when Group B have completed doing ticket 456. Will I be able to see any updates despite the fact the the ticket is assigned to someone outside my group?
0
Dane
You'll be notified of any updates as long as you are the requester on the side conversation/child ticket created. You can also access it as long as the requester field has not been changed. I tested it on my end. You can access it via the side conversation tab or click the actual ticket number.
0