Can Agent Chat broadcast new chat requests to all available agents simultaneously?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 hours ago
Hi Community,
We are using ServiceNow Agent Chat with Advanced Work Assignment (AWA) and have a requirement where every new incoming chat should notify all available agents simultaneously, allowing the first agent who accepts the chat to receive the assignment.
From my research, I found that ServiceNow Agent Chat does not natively support broadcasting a single chat invitation to all available agents. Instead, AWA appears to evaluate eligible agents and route the interaction to one agent based on the configured assignment strategy (Most Available, Round Robin, Last Assigned, etc.).
Our requirement:
- New chat arrives.
- All eligible and available agents receive a notification/pop-up at the same time.
- The first agent to accept gets the chat.
- The notification disappears for everyone else once accepted.
I understand this is not supported out of the box, but I'm looking for possible workarounds.
Questions:
- Has anyone successfully implemented a broadcast or "first-to-accept" model for Agent Chat?
- Did you use custom Workspace notifications, UI Notifications, WebSockets, or any other custom solution?
- Is there any supported approach using AWA, Interaction records, or Agent Workspace extensions?
- Are there any performance or scalability concerns with custom broadcasting?
Any recommendations or implementation experiences would be greatly appreciated.
Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
25m ago
Your understanding is correct. Out of the box, AWA is designed to route a work item to an eligible agent based on the configured assignment method. It is not designed as a broadcast or “first agent to accept wins” mechanism.
For this requirement, I would not recommend modifying the OOTB AWA routing logic.
A possible custom approach would be:
When the chat/interaction is created, identify all eligible agents based on the same availability, group, skills, capacity, and presence rules used for routing.
Send a custom Workspace notification to those agents.
When an agent clicks Accept, use a server-side action to atomically check whether the interaction is still unassigned.
If it is still available, assign it to that agent and continue the normal processing.
If another agent has already accepted it, return a message that the chat has already been assigned.
After successful assignment, remove or invalidate the notification for the remaining agents.
The important part is the server-side locking/validation. You should not rely only on the Workspace UI because multiple agents could click Accept at almost the same time.
I would avoid directly creating multiple AWA work assignments for the same interaction. That can interfere with AWA capacity, routing state, agent availability, and reporting.
Custom Workspace notifications or a custom UI component are safer than trying to change the core AWA assignment engine. WebSockets should generally not be necessary because ServiceNow Workspace already has mechanisms for real-time updates.
There can also be scalability concerns. If every incoming chat generates notifications for a large number of agents, the number of events and UI updates can grow quickly. I would limit broadcasting to a specific eligible group and carefully test concurrency and performance.
So, technically this can be implemented as a customization, but it is not the standard AWA routing model. If this is a production requirement, I would also confirm the design with ServiceNow Support before implementing it, especially if the solution needs to interact with AWA availability, capacity, or work item state.
