Genesys Cloud - Developer Community!

In Genesys Cloud, we would like to add a custom call button to the script that is displayed to the agent during ACW (After Call Work).

Is it possible to configure outbound dialing to an external phone number via an operation such as pressing a button on the script, using Genesys Cloud Function Data Action?
If there are any APIs or standard features better suited for outbound dialing, please let us know as well.

Additionally, we are concerned that actions such as executing the Conversation API may fail due to authentication issues.

We would appreciate your guidance on recommended implementation methods using Genesys Cloud Function Data Action, as well as any restrictions regarding authentication, permissions, or agent state.

#DataActions

------------------------------
YONETSU EMI
-
------------------------------

Hi Yonetsu,

I haven't implemented this exact scenario, but I found a couple of community threads that may help.

If your requirement is to create a new outbound call, the relevant endpoint appears to be POST /api/v2/conversations/calls. One important consideration is that this API requires a user context because Genesys derives the originating party from the authenticated user's active phone. A client credentials OAuth token (such as one used by a Data Action or Cloud Function) does not have a user context, so it cannot place the call on behalf of an agent. 

I also found that the agent's phone may need the "Allow apps to place calls" setting enabled when using this API. 

Based on that, I'd be interested to hear what others have implemented for launching a new outbound call directly from an Agent Script during ACW, as authentication and user context seem to be the key considerations.

References:

• https://community.genesys.com/discussion/error-when-using-apiv2conversationscalls-in-data-action
• https://community.genesys.com/discussion/post-apiv2conversationscalls-creating-interactions-with-a-single-participant

Hope this helps.

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

Hello,

Please note that a new endpoint has been introduced recently to allow to place calls on behalf of a user (using Client Credentials Grant token).

It is the "POST /api/v2/conversations/calls/user/{userId}" endpoint.

The user still needs to have "Placing calls with another app?" enabled for the call to take place properly.

Regards,

------------------------------
Jerome Saint-Marc
Senior Development Support Engineer
------------------------------

Original Message:
Sent: 08-06-2026 05:08
From: Phaneendra Avatapalli
Subject: Is it possible to use Genesys Cloud Function Data Action to add a call button to the script during ACW and initiate an outbound call?

Hi Yonetsu,

I haven't implemented this exact scenario, but I found a couple of community threads that may help.

If your requirement is to create a new outbound call, the relevant endpoint appears to be POST /api/v2/conversations/calls. One important consideration is that this API requires a user context because Genesys derives the originating party from the authenticated user's active phone. A client credentials OAuth token (such as one used by a Data Action or Cloud Function) does not have a user context, so it cannot place the call on behalf of an agent. 

I also found that the agent's phone may need the "Allow apps to place calls" setting enabled when using this API. 

Based on that, I'd be interested to hear what others have implemented for launching a new outbound call directly from an Agent Script during ACW, as authentication and user context seem to be the key considerations.

References:

• https://community.genesys.com/discussion/error-when-using-apiv2conversationscalls-in-data-action
• https://community.genesys.com/discussion/post-apiv2conversationscalls-creating-interactions-with-a-single-participant

Hope this helps.

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

Hello, 

Thank you all very much for your advice.

As Mr. Jerome mentioned, and as described in the following IdeasLab information, we found details on an API for making calls without user context, and this was effective.

https://genesyscloud.ideas.aha.io/ideas/OPAPISDK-I-1

Regarding making a new outbound call to an external contact from a script displayed during ACW, we were able to achieve this by configuring a data action in the script's button click action to execute the API "POST /api/v2/conversations/calls/user/{userId}".

------------------------------
YONETSU EMI
-
------------------------------

Original Message:
Sent: 08-12-2026 06:40
From: Jerome Saint-Marc
Subject: Is it possible to use Genesys Cloud Function Data Action to add a call button to the script during ACW and initiate an outbound call?

Hello,

Please note that a new endpoint has been introduced recently to allow to place calls on behalf of a user (using Client Credentials Grant token).

It is the "POST /api/v2/conversations/calls/user/{userId}" endpoint.

The user still needs to have "Placing calls with another app?" enabled for the call to take place properly.

Regards,

------------------------------
Jerome Saint-Marc
Senior Development Support Engineer
------------------------------


Original Message:
Sent: 08-06-2026 05:08
From: Phaneendra Avatapalli
Subject: Is it possible to use Genesys Cloud Function Data Action to add a call button to the script during ACW and initiate an outbound call?

Hi Yonetsu,

I haven't implemented this exact scenario, but I found a couple of community threads that may help.

If your requirement is to create a new outbound call, the relevant endpoint appears to be POST /api/v2/conversations/calls. One important consideration is that this API requires a user context because Genesys derives the originating party from the authenticated user's active phone. A client credentials OAuth token (such as one used by a Data Action or Cloud Function) does not have a user context, so it cannot place the call on behalf of an agent. 

I also found that the agent's phone may need the "Allow apps to place calls" setting enabled when using this API. 

Based on that, I'd be interested to hear what others have implemented for launching a new outbound call directly from an Agent Script during ACW, as authentication and user context seem to be the key considerations.

References:

• https://community.genesys.com/discussion/error-when-using-apiv2conversationscalls-in-data-action
• https://community.genesys.com/discussion/post-apiv2conversationscalls-creating-interactions-with-a-single-participant

Hope this helps.

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

__________________________________________________________________________________________________________________________________________________________________

------------------------------
Matheus Mendonca
------------------------------

Hi Yonetsu,

One additional option I would test before moving to a custom OAuth application is the native callback capability from the Script.

If the second phone number is already available in the Script, you could use Scripter.Schedule Callback and pass that number together with the queue and the current agent as the preferred agent.

The behavior I would test is:

Agent is in ACW
→ clicks the button and creates the callback
→ completes ACW
→ becomes available
→ callback is routed back to the same agent

It would not be 100% immediate in the same way as originating a new outbound call, since the callback still follows the ACD/routing model, but depending on your requirement it could be a simple native workaround.

https://help.mypurecloud.com/articles/add-a-schedule-callback-option-to-a-script/

Regarding the direct API approach, even if you collect the current user ID from the Script using Scripter.Agent ID and pass it to a Data Action, that does not change the authentication context.

The Data Action/Function is still executed using its own OAuth credentials, typically Client Credentials, not as the agent who clicked the button. Passing the agent ID in the request does not make the API call execute on behalf of that user.

So if the requirement is that the new outbound call must actually start immediately while the agent is still in ACW, then I think the authentication/user-context considerations already mentioned in this thread apply.

As a last alternative, the agent could always place the outbound call manually from Genesys Cloud, although I assume the goal here is precisely to avoid that extra manual step.

I would definitely test the native callback approach first and see if creating it during ACW and completing ACW immediately afterward gives you an acceptable experience.

I hope this adds another useful option to the discussion.

Best regards.

------------------------------
Raphael Poliesi
------------------------------

Hi Yonetsu,

Interesting use case. From a support and operational perspective, I would also consider how the outbound call would be represented and troubleshot if it is initiated while the agent is still in ACW.

If the native callback approach is used, it seems that keeping the interaction within the normal ACD/routing flow could also make the interaction easier to track and troubleshoot compared with initiating a separate outbound call through a custom integration.

I would be interested to know whether maintaining the interaction history and reporting is also part of the requirement, or if the main goal is simply to allow the same agent to call the customer back as quickly as possible after the original interaction.

Thanks for sharing the scenario.

------------------------------
Mcel Turalba | Genesys
Support Product Engineer
------------------------------

Based on the information available in the search results, I can provide some guidance on this requirement, and this is a topic that has been discussed in the Genesys community where a few important points have emerged regarding the feasibility of this approach. The primary challenge you identified regarding authentication is indeed the most critical one, because to initiate an outbound call using the Conversation API, specifically the POST /api/v2/conversations/calls endpoint, you must use an OAuth token that includes a user context, meaning the token must be obtained through an authorization flow where a specific agent is authenticated, such as the Authorization Code Grant or SAML2 Bearer grant. Here is the fundamental issue: a Client Credentials OAuth token, which is typically what a Genesys Cloud Function or a Data Action uses for server-to-server communication, does not have a user context, and because of this, a standard Data Action using a client credentials token is technically unable to place a call on behalf of an agent, since the API derives the originating party from the authenticated user associated with the token, and without a user, it cannot initiate the call. This is a deliberate security measure by Genesys Cloud to ensure calls are only placed by authorized and identifiable users.

While a direct call via a Data Action is likely not feasible, there are a few other avenues to consider for this functionality. The most straightforward approach may be to design a Campaign for this purpose, and it was noted in a community discussion that you could potentially use an outbound campaign to dial a number and route the call into a specific queue, possibly even designating a specific agent as a preferred agent. While this might introduce more complexity, it is a viable path that works within the platform's security model without needing a user-context token. Another possible method involves leveraging a Script with Agent Context, where if you can design a solution where the button in the script sends a request to a backend service like a Cloud Function, but that service is able to use an OAuth token that was obtained with the agent's context, this could work. However, this is a significant architectural challenge, as it requires securely managing user tokens on the agent's behalf. A different, albeit less efficient, approach would be to have the button on the script provide the agent with the phone number to dial manually, which could be done by having the button copy the phone number to the clipboard, and the agent would then use their standard Genesys Cloud interface or a third-party dialer to place the call, which does not automate the call initiation but does streamline the process by eliminating the need for the agent to manually copy and paste the number.

For any outbound call, including those initiated via API, there are some additional considerations to keep in mind. The agent must have the appropriate permissions to place outbound calls, and specifically, it may be necessary for the agent's phone configuration to have the "Allow apps to place calls" setting enabled for this API-based approach to function. The agent will also need to be in a state that allows them to receive or place a new call, such as "On Queue" or a similar ready state, and initiating a call during ACW might require the agent to first complete their wrap-up or change their status before the outbound call can be placed. It is also worth noting that a native workaround exists where the system's default wrap-up button cannot be removed, but you can train agents to use a custom script's "Done" button to trigger API calls, handling the ACW process first before initiating a new call.

Given the constraints, here is a summary of recommended paths for your implementation. First, the primary recommendation is to explore a campaign approach, because given the hard limitation on using a Data Action, the most reliable native Genesys Cloud method is likely to use an outbound campaign where you can configure the campaign to dial the external number and route the call, and this is a fully supported and secure way to automate outbound dialing. Second, as a secondary recommendation, if your business absolutely requires the button in a script model, you would need to build a custom solution where your Genesys Cloud Function obtains a user-context token for the specific agent, though this is a complex and advanced pattern but is technically possible. Third, it is important to understand that direct API via script is not feasible, as a standard Data Action with a client credentials token will not work due to the lack of user context. Finally, regardless of the chosen path, any solution that involves API calls and placing calls should be rigorously tested in a non-production environment to ensure the correct permissions are in place and the agent state management behaves as expected before moving to production.

In conclusion, your suspicion about authentication issues is correct, and it represents the primary obstacle, so the native API route with a Data Action is not viable. I would recommend evaluating the campaign approach as the most straightforward and supported path forward, and if a custom script button solution is non-negotiable, it will require a sophisticated authentication flow to provide a user-context token to your service.

------------------------------
Camila Meneghini
------------------------------