How can we control the visibility of queues in Agent chat of SOW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
How can we control the visibility of queues in Agent chat of SOW.
OOB, all active queues are shown in chat so sometimes agent may route ticket to different queue
We want to show only specific queues to Agent based on Agent's location.
I tried ACL but it's not working
Is there any other way to achieve this ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
a week ago
Hi @Balakrishna_ABK,
Before touching ACLs again, check where that /tq list actually comes from. The Transfer to Queue quick action in Agent Chat reads straight off the Live Agent Queue [awa_queue] table, and the script backing that quick action almost always does it with a plain GlideRecord, not a GlideRecordSecure. Plain GlideRecord does not enforce row-level ACLs by default, only code paths that explicitly run a security check do, things like list views, REST, or GlideRecordSecure. That is exactly why your ACL on awa_queue got silently ignored: nothing in that flow was ever asking the question the ACL answers.
What does work reliably here is a before-query Business Rule on Live Agent Queue [awa_queue]. Query business rules fire at the query level itself, so they apply no matter what script or widget issued it, elevated context or not. Add a location field to awa_queue (reference to cmn_location, or whatever field you already key agent location off), populate it per queue, then in the before-query BR add something like current.addQuery('u_location', gs.getUser().getLocation()).
One catch worth flagging: awa_queue is not only read by the picker, the AWA routing engine queries the same table to actually assign work items to groups. If the BR is not scoped tightly, I would gate it on gs.getSession().isInteractive(), or only fire when a location value is actually populated, you risk filtering the backend routing right along with the UI list. Test with live chat traffic in a sub-prod instance, not just the quick action dialog, before you roll it out.
Also worth separating two things people conflate here: Assignment Eligibility on a queue controls who work items get routed to once a chat lands in that queue. It does nothing for what appears in the /tq picker itself, those are two different problems with two different fixes. If all you needed was correct routing you would not need any of this, but since you specifically want agents to never even see the wrong queue as an option, the query business rule is the piece that actually touches the list.
Thank you,
Vikram Karety
Octigo Solutions INC