Hi Karine,
I have seen this (or very similar scenarios) implemented before a few times, and I haven't personally seem any issues.
I'm not sure what you mean by "slow database performance". Are you having any issues regarding that when trying to implement this solution?
The workflow works fine, but the documentation mentions that there could be delays to events (so the trigger that would start an workflow could be delayed in some cases), but I haven't personally seem this happening.
Regarding how API calls are handled.. Well, after the trigger starts an workflow, you should be able to run the Genesys Cloud APIs using Data Actions, so you will be able to PATCH an agent's status to "On Queue", etc. There are limits to Data Actions and APIs that need to be observed (Like the number of concurrent Data Actions running at a time, or the number of API calls per minute/hour, etc..), so some of those limits could be an issue depending on the rest of your organization (How many other data actions you are running throught the whole organization, etc., as most of those limits are global).
------------------------------
Marcello Jabur
------------------------------
Original Message:
Sent: 05-20-2026 09:49
From: Karine Alves
Subject: Forcing agent into "In queue" status
I have a question for anyone who has implemented a customization using architect and triggers to keep an agent in a queue, preventing it from getting into other statuses due to inattention or intentionally.
How does the issue of slow database performance work, how are API calls handled? Does the workflow function well? If it does, and you have a large number of licenses, what problems have you observed after implementation?
#Scripts
#Triggers
------------------------------
Karine Alves
Project manager
------------------------------