Genesys Cloud - Main

Hi everyone,

We recently implemented a workflow to automatically return agents On Queue after completing outbound calls if they forget to manually change their status.

Our use case is a dedicated outbound queue where agents manually select an Outbound status (Off Queue) to make outbound calls. Occasionally, agents would finish their outbound interaction and forget to return On Queue, leaving them unavailable for inbound ACD interactions.

Our workflow is:

• Trigger on v2.detail.events.conversation.{id}.acw.
• Filter the trigger to our dedicated Outbound queue.
• Wait 30 seconds.
• Check the agent’s routing status using:

GET /api/v2/users/{userId}/routingstatus

• If the routing status is still OFF_QUEUE, update the user's presence using:

PATCH /api/v2/users/{userId}/presences/purecloud

and set the user's presence to On Queue.

• If the agent is no longer OFF_QUEUE (for example, they've already changed their status or started another interaction), the workflow simply ends without making any changes.

Initially, we tried using:

PUT /api/v2/users/{userId}/routingstatus

However, we found that endpoint is intended for recovering agents from NOT_RESPONDING and is not the correct approach for returning an agent from OFF_QUEUE to On Queue.

To update the user's presence, first retrieve the On Queue Presence Definition ID using:

GET /api/v2/presencedefinitions

Locate the Presence Definition where systemPresence = On Queue, then use the returned id as the presenceDefinition.id value in the body of the PATCH request.

One thing to be aware of is that updating another user's presence requires the Presence > User Presence > Edit (presence:userPresence:edit) permission, as outlined in the Genesys announcement below:

https://help.mypurecloud.com/announcements/permission-enforcement-change-to-update-another-users-presence-with-patch-api/

Hopefully this helps anyone looking to solve a similar use case. I'd also be interested to hear if anyone has implemented this differently or has any suggestions for further improvements.

#API/Integrations

------------------------------
Phaneendra
Technical Solutions Consultant
------------------------------

Thank you Raphael! That's a great point. In our case the workflow is already triggered from the outbound queue's ACW event, but I like the idea of validating the current presenceDefinition.id as an additional safeguard before updating the presence. I'll look at adding that check so the workflow only returns agents to On Queue if they're still in our dedicated Outbound presence

Your workflow is a smart safety net that addresses a very real operational pain point agents finishing outbound calls and accidentally staying offline, which causes them to miss incoming interactions. The core logic is sound: you're waiting a short period after the call's wrap-up phase ends, then checking whether the agent has remembered to put themselves back into the available state. If they haven't, your automation steps in to correct it. The 30-second buffer is particularly thoughtful, as it gives agents a fair chance to handle any post-call tasks before the system intervenes, reducing the risk of frustrating someone who was simply finishing their notes.

However, the technical execution could be refined in a couple of areas. Instead of updating the agent's broader "presence" which covers states like "Break" or "Meeting" and requires you to fetch specific definition IDs you could use a more direct endpoint that specifically targets routing availability. This approach is cleaner because it changes only whether the system considers the agent eligible to receive new interactions, without accidentally overriding other statuses they might have set intentionally. It also requires a narrower permission set, making it easier to secure and audit within your organization's role-based access controls.

The biggest hidden risk in your current design is the timing relative to the agent's actual workload. If your workflow fires exactly 30 seconds after wrap-up ends, it might catch agents who are already on a new call, incorrectly forcing them "available" while they're actively speaking with another customer. This could confuse the routing engine and potentially assign them another interaction they can't handle. Adding a quick verification step, checking whether they're currently engaged in any active conversatio, would eliminate this edge case entirely. Similarly, implementing a short cooldown period or tracking when an agent was last auto-returned would prevent the system from repeatedly triggering corrections for the same person in a short timeframe.

Ultimately, your solution is already highly functional and demonstrates a strong grasp of Genesys Cloud's automation capabilities. With the minor adjustments mentioned switching to the routing-specific endpoint, adding a conversation check, and optionally implementing a tracking mechanism you'd have a production-grade safeguard that balances agent autonomy with operational efficiency. The permission caveat you highlighted is especially valuable, as it's a common stumbling block that often goes unnoticed until deployment. Thank you for sharing this; it's a practical contribution that will undoubtedly help others facing similar outbound-to-inbound transition challenges.

Thank you Camila for taking the time to review the solution and for the thoughtful suggestions.

You raise a good point about ensuring we don't inadvertently override an intentional Off Queue status. Based on similar feedback, we've refined the workflow further.

Rather than checking only whether the agent's routing status is OFF_QUEUE, the workflow now also retrieves the user's current presence and verifies that they're still in our dedicated Outbound presence before updating them back to On Queue. This ensures that if an agent has intentionally changed their presence to something like Break, Meal, or Training, the workflow will simply exit without making any changes.

We also looked at using the routing status endpoint directly, but found that PUT /api/v2/users/{userId}/routingstatus is intended for recovering agents from NOT_RESPONDING and doesn't support returning an agent from OFF_QUEUE to On Queue. Using the Presence API was the supported approach that worked for this use case.

Thanks again for the feedback it helped us make the workflow even more robust.