Genesys Cloud - Main

Hi @Phaneendra Avatapalli

Since your assignment data action works in both the test UI and in Architect Workflows but fails with a 405 error from Scripts, there's likely a difference in how Scripts execute data actions versus other contexts.

To help troubleshoot, can you check:

1. What type of integration is your data action using? 
   1. Assumption this may be a Web Services Data Actions
2. What HTTP method is configured in your assignment data action? (GET, POST, PUT, PATCH, DELETE?)
3. Does the agent have these permissions:
   • Integrations > Action > View
   • Bridge > Actions > Execute

Immediate things to verify:

1. Ensure the ticket ID output variable from the creation step is properly assigned and passed to the assignment action input
2. Verify "Data Actions" is enabled in your Script properties
   1. 
3. Check that both the ticket ID and agent name values are populated before the assignment call
4. For all the inputs used within the script custom action you can create "holders" within your script page to ensure they are populated with what you expect, this will allow you to see them first hand on the script page itself as opposed to assuming they have what you expect. 

The 500 error you're seeing likely means the Function isn't receiving the expected inputs, this comes back to starting with point 4 above to ensure what is being passed in is what is expected and also what is tested within the Data Action UI & Workflow

Hi Josh, 

Thank you for responding

Just wanted to share that I got this working from the script button in the end.

Hi @Phaneendra Avatapalli

Since your assignment data action works in both the test UI and in Architect Workflows but fails with a 405 error from Scripts, there's likely a difference in how Scripts execute data actions versus other contexts.

To help troubleshoot, can you check:

1. What type of integration is your data action using? 
   1. Assumption this may be a Web Services Data Actions
2. What HTTP method is configured in your assignment data action? (GET, POST, PUT, PATCH, DELETE?)
3. Does the agent have these permissions:
   • Integrations > Action > View
   • Bridge > Actions > Execute

Immediate things to verify:

1. Ensure the ticket ID output variable from the creation step is properly assigned and passed to the assignment action input
2. Verify "Data Actions" is enabled in your Script properties
   1. 
3. Check that both the ticket ID and agent name values are populated before the assignment call
4. For all the inputs used within the script custom action you can create "holders" within your script page to ensure they are populated with what you expect, this will allow you to see them first hand on the script page itself as opposed to assuming they have what you expect. 

The 500 error you're seeing likely means the Function isn't receiving the expected inputs, this comes back to starting with point 4 above to ensure what is being passed in is what is expected and also what is tested within the Data Action UI & Workflow

Hi Josh,

Thank you for your guidance and the valuable inputs, really appreciate it.

After weighing all the options with the business, we decided to go with the Script button approach to create tickets in the CRM. This helped us keep the process simple and avoid creating unnecessary tickets unless the agent explicitly triggers it.

We also looked at the ACW and wrap-up trigger approaches, but:

• with ACW triggers, the ticket was only created after the full ACW completed, which did not align with the requirement not sure if this is configurable or does it behave same for all orgs
• with wrap-up triggers, it relied on system wrap-up or required setting wrap-up in the call/in-queue flow, which could introduce a risk of duplicate ticket creation,

At the very least, the Script approach also lets us display the incident/reference back to the agent immediately, so they can click and open the incident directly if needed.

So for our use case, the Script-based option ended up being the most controlled and predictable approach.

Thanks again for the support.

Awesome, glad you found an approach that works! The Script button route is solid for this kind of controlled ticketing. Nice work @Phaneendra Avatapalli!

Hi Josh,

Thank you for your guidance and the valuable inputs, really appreciate it.

After weighing all the options with the business, we decided to go with the Script button approach to create tickets in the CRM. This helped us keep the process simple and avoid creating unnecessary tickets unless the agent explicitly triggers it.

We also looked at the ACW and wrap-up trigger approaches, but:

• with ACW triggers, the ticket was only created after the full ACW completed, which did not align with the requirement not sure if this is configurable or does it behave same for all orgs
• with wrap-up triggers, it relied on system wrap-up or required setting wrap-up in the call/in-queue flow, which could introduce a risk of duplicate ticket creation,

At the very least, the Script approach also lets us display the incident/reference back to the agent immediately, so they can click and open the incident directly if needed.

So for our use case, the Script-based option ended up being the most controlled and predictable approach.

Thanks again for the support.