Genesys Cloud - Main

Dear all,

Has anyone successfully used a Genesys Script button to create a ticket/record in an external system and then assign it to the current agent handling the interaction?

I have a Script-based flow that is working for almost everything. From the script, I can successfully:

• authenticate to the external system
• look up the customer
• create the ticket/record
• retrieve the returned key/reference needed for update
• prepare the value needed for the final update step

What I'm trying to do:

Use the current connected agent from the script, ideally something like Scripter.Agent Name, and pass that into the final update so the ticket/record is assigned to that agent.

The only part causing trouble is the final assignment/update step.

What I've observed so far:

• the update/assign call works when tested directly in the data action
• similar logic also works in a Workflow-based design
• but when the final assign step was executed directly from the Script path, I was getting 405: Method Not Allowed
• to work around that, I moved the final assign step into a Genesys Function
• after shifting it to the Function, the error changed to 500: Internal Server Error, so I'm now trying to work out whether the issue is the value being passed from the Script, the assignee format, or the final update call itself

So I'm interested to know:

• has anyone done this successfully from a Script button?
• did you use Scripter.Agent Name directly, or did you resolve the agent another way first?
• did you notice any difference between Script execution vs Workflow/Data Action testing?
• did moving the final update into a Function help in your case?
• were there any gotchas around passing the returned key/reference or the agent value from the Script into the final update step?

Interested to hear how others have approached this pattern and any lessons learned.

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

Dear all,

Has anyone successfully used a Genesys Script button to create a ticket/record in an external system and then assign it to the current agent handling the interaction?

I have a Script-based flow that is working for almost everything. From the script, I can successfully:

• authenticate to the external system
• look up the customer
• create the ticket/record
• retrieve the returned key/reference needed for update
• prepare the value needed for the final update step

What I'm trying to do:

Use the current connected agent from the script, ideally something like Scripter.Agent Name, and pass that into the final update so the ticket/record is assigned to that agent.

The only part causing trouble is the final assignment/update step.

What I've observed so far:

• the update/assign call works when tested directly in the data action
• similar logic also works in a Workflow-based design
• but when the final assign step was executed directly from the Script path, I was getting 405: Method Not Allowed
• to work around that, I moved the final assign step into a Genesys Function
• after shifting it to the Function, the error changed to 500: Internal Server Error, so I'm now trying to work out whether the issue is the value being passed from the Script, the assignee format, or the final update call itself

So I'm interested to know:

• has anyone done this successfully from a Script button?
• did you use Scripter.Agent Name directly, or did you resolve the agent another way first?
• did you notice any difference between Script execution vs Workflow/Data Action testing?
• did moving the final update into a Function help in your case?
• were there any gotchas around passing the returned key/reference or the agent value from the Script into the final update step?

Interested to hear how others have approached this pattern and any lessons learned.

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

Dear all,

Has anyone successfully used a Genesys Script button to create a ticket/record in an external system and then assign it to the current agent handling the interaction?

I have a Script-based flow that is working for almost everything. From the script, I can successfully:

• authenticate to the external system
• look up the customer
• create the ticket/record
• retrieve the returned key/reference needed for update
• prepare the value needed for the final update step

What I'm trying to do:

Use the current connected agent from the script, ideally something like Scripter.Agent Name, and pass that into the final update so the ticket/record is assigned to that agent.

The only part causing trouble is the final assignment/update step.

What I've observed so far:

• the update/assign call works when tested directly in the data action
• similar logic also works in a Workflow-based design
• but when the final assign step was executed directly from the Script path, I was getting 405: Method Not Allowed
• to work around that, I moved the final assign step into a Genesys Function
• after shifting it to the Function, the error changed to 500: Internal Server Error, so I'm now trying to work out whether the issue is the value being passed from the Script, the assignee format, or the final update call itself

So I'm interested to know:

• has anyone done this successfully from a Script button?
• did you use Scripter.Agent Name directly, or did you resolve the agent another way first?
• did you notice any difference between Script execution vs Workflow/Data Action testing?
• did moving the final update into a Function help in your case?
• were there any gotchas around passing the returned key/reference or the agent value from the Script into the final update step?

Interested to hear how others have approached this pattern and any lessons learned.