Play mode automatically serves tickets which are not being looked at by other agents. So a group of people could be playing tickets from a view, and the expectation is that the system avoids agent collision, and never gives them a ticket that another user is currently present on.
This feature works as defined above if:
- All the tickets in this view are never ever looked at by anyone else outside this group
- Every agent in the group is always playing these tickets using Play button
- No agent is allowed to open tickets from the view in any different way
However there are a few scenarios in which an agent in play mode may be served a ticket that already has someone on it. In this article, we'll explain these scenarios, and how to avoid them.
This article includes the following topics:
For more information on agent collision and Play mode, see Working with tickets.
Scenarios for potential agent collision in Play mode
There are three relatively common scenarios that may lead to agent collision in Play mode:
Scenario 1: Another agent manually opens a ticket
If an agent is looking at a ticket in Play mode, there is nothing to stop another agent who is not in play mode from manually opening that ticket (e.g. after finding it in a search). The agent in Play mode will then see someone else is on their ticket and think that Play mode is not working correctly.
Scenario 2: Losing connection while in Play mode
Assume that agents A and B are using Play mode. While playing these tickets, everything seems to be fine. Then A leaves for lunch, with a ticket tab open. (Let's say ticket T). She is online on ticket T and then while at lunch an issue occurs—she loses network connectivity. This loss could be caused by the Internet going down for a while or her laptop going into sleep mode. Agent A is now no longer online and so the system no longer thinks that agent A is on the ticket.
Agent B then gets served ticket T during playing, and he works on the ticket. That's when agent A finishes her lunch and taps a key on her laptop. It wakes up, and instantly Agent A is now online on ticket T. B sees this, and says, "I thought this Play button was never supposed to give me tickets being looked at by other agents!"
Scenario 3: Losing connection outside of Play mode
Assume the following occurs:
- Agent A and Agent B are not using play mode
- Agent B opens ticket T
- Agent A then opens ticket T and is shown a message telling her that the ticket is also open with Agent B
- Agent A loses internet connectivity and the message still remains
- Agent B closes ticket T
- Agent A come back online and still see the message, even though agent B is no longer on the ticket
Identifying and addressing agent collision in Play mode
To identify and address Play mode or agent presence issues, you should look into the following:
Clear the browser cache and cookies
Zendesk uses various cookies to manage agent presence and so if you have issues the first thing to have agents do is to refresh these cookies regularly. See Options to clear cache and cookies for how to do this.
Agent Presence URLs
Connections to Zendesk to ascertain whether an agent is on a ticket are not made via the same URL as the requests to the rest of Zendesk (such as mydomain.zendesk.com
), but rather via a URL of the form pubsub-shardC-P-N.zendesk.com
, where:
- C is the cluster of the account (this is a value between 1 and 3)
- P is the pod of the account
- N is a random number from 1 to 4
For example, using Chrome’s developer tools and, filtering by pubsub, we see the url is https://pubsub-shard2-17-3.zendesk.com
:

In the above example, for this specific account:
- C = 2
- P = 17
- N = 3 , but could have been any number between 1 and 4
So the following URLs should be allowed for this account, and allowed in your VPN, firewall, and any antivirus software you are using:
https://pubsub-shard2-17-1.zendesk.com
https://pubsub-shard2-17-2.zendesk.com
https://pubsub-shard2-17-3.zendesk.com
https://pubsub-shard2-17-4.zendesk.com
Long periods of agent inactivity
Agent collision can happen due to long periods of inactivity on a ticket. When the screen is not active, the system does not register that the agent is working on the ticket.
See Avoiding agent collision for information on identifying agents viewing, editing, or idling in a ticket.
Agents logged into multiple devices
Agents logged into Zendesk on multiple devices can prevent the system from registering what tickets are being worked on. This can keep the agent collision feature from working correctly.
Manually taking tickets
If agents are using the play button and an agent manually takes a ticket, this can cause agent collision (see scenario #1 above)
0 Comments
Please sign in to leave a comment.