Genesys Cloud - Main

Hi everyone,

I'm currently working on a Genesys Cloud + BMC Helix integration for incident creation and assignment, and wanted to sanity check the best approach.

I've got incident creation and assignment working end-to-end, but I'm running into a couple of edge cases with the current design:

• if a customer abandons while waiting in queue, the ticket gets created but is not assigned to anyone
• if an agent does not answer and the call reroutes, the ticket still gets created and gets assigned to first agent who missed the call.

I'm looking at two options:

Option 1 – Workflow-based

I'm planning to use a trigger/workflow and identify the final agent who handled the interaction before creating and assigning the incident.

The idea is to call the Conversation API, filter participants where purpose="agent" and the message state is connected, return the matching agent list, and then take the last agent using:

GetAt(agentNames, Count(agentNames) - 1)

At the moment this is more of a design idea I'm exploring, so I'd be interested to know whether this is a reliable pattern, and also whether there is a better API/event to identify when an agent is actually fully connected to the interaction.

Option 2 – Agent Script button

Alternatively, I'm thinking of moving this into an Agent Script button, where the agent clicks once connected and the process runs from there. My understanding is that Scripts can execute data actions, custom script actions can chain multiple steps, and Function data actions can also be called from Scripts. So the idea would be something like: JWT → People Lookup → create incident → assign incident.

Just wanted to ask:

• Has anyone implemented either of these approaches successfully?
• Is using the last connected agent from the Conversation API a reliable pattern?
• Is there a better way to detect when the agent is truly connected?
• Can this be done cleanly from Agent Script buttons using data actions or function data actions.

Would appreciate any advice or real-world experience.

#ArchitectandDesign

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

Hi @Phaneendra Avatapalli

I'd recommend going with your workflow-based approach with one simple adjustment.

The key: Wait to create the ticket until after the agent completes their wrap-up work. This naturally solves both issues you're running into:

• If a customer abandons while waiting > no agent wrap-up happens > no ticket gets created
• If an agent doesn't answer > no wrap-up happens > no ticket gets created
• Only interactions where an agent actually helped the customer will create tickets

For finding the right agent: Your idea to identify the last agent who was connected to the call is the right approach. Just make sure you're filtering for agents who actually answered (not just received an alert). This will handle transfer scenarios correctly too.

On the Script button idea: While it's doable, it relies on agents remembering to click the button every time, which can lead to inconsistency. The automated workflow is more reliable and is actually a better approach for these types of integrations.

Hope this helps you with your decision.

Hi everyone,

I'm currently working on a Genesys Cloud + BMC Helix integration for incident creation and assignment, and wanted to sanity check the best approach.

I've got incident creation and assignment working end-to-end, but I'm running into a couple of edge cases with the current design:

• if a customer abandons while waiting in queue, the ticket gets created but is not assigned to anyone
• if an agent does not answer and the call reroutes, the ticket still gets created and gets assigned to first agent who missed the call.

I'm looking at two options:

Option 1 – Workflow-based

I'm planning to use a trigger/workflow and identify the final agent who handled the interaction before creating and assigning the incident.

The idea is to call the Conversation API, filter participants where purpose="agent" and the message state is connected, return the matching agent list, and then take the last agent using:

GetAt(agentNames, Count(agentNames) - 1)

At the moment this is more of a design idea I'm exploring, so I'd be interested to know whether this is a reliable pattern, and also whether there is a better API/event to identify when an agent is actually fully connected to the interaction.

Option 2 – Agent Script button

Alternatively, I'm thinking of moving this into an Agent Script button, where the agent clicks once connected and the process runs from there. My understanding is that Scripts can execute data actions, custom script actions can chain multiple steps, and Function data actions can also be called from Scripts. So the idea would be something like: JWT → People Lookup → create incident → assign incident.

Just wanted to ask:

• Has anyone implemented either of these approaches successfully?
• Is using the last connected agent from the Conversation API a reliable pattern?
• Is there a better way to detect when the agent is truly connected?
• Can this be done cleanly from Agent Script buttons using data actions or function data actions.

Would appreciate any advice or real-world experience.

#ArchitectandDesign

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

Hi Josh,

Thank you, this is really helpful and makes a lot of sense especially using ACW to ensure the ticket is only created when an agent actually handles the interaction.

Just a quick follow-up question: in scenarios like transfers or callbacks, is there a possibility of multiple agents being involved and therefore multiple ACW events for the same conversation?

If so, would you recommend handling this with a safeguard (e.g. checking if a ticket is already created) or is there a better way to ensure the ticket is only created once and assigned to the correct final agent?

Thanks again for the guidance!

Hi @Phaneendra Avatapalli

I'd recommend going with your workflow-based approach with one simple adjustment.

The key: Wait to create the ticket until after the agent completes their wrap-up work. This naturally solves both issues you're running into:

• If a customer abandons while waiting > no agent wrap-up happens > no ticket gets created
• If an agent doesn't answer > no wrap-up happens > no ticket gets created
• Only interactions where an agent actually helped the customer will create tickets

For finding the right agent: Your idea to identify the last agent who was connected to the call is the right approach. Just make sure you're filtering for agents who actually answered (not just received an alert). This will handle transfer scenarios correctly too.

On the Script button idea: While it's doable, it relies on agents remembering to click the button every time, which can lead to inconsistency. The automated workflow is more reliable and is actually a better approach for these types of integrations.

Hope this helps you with your decision.

Hi everyone,

I'm currently working on a Genesys Cloud + BMC Helix integration for incident creation and assignment, and wanted to sanity check the best approach.

I've got incident creation and assignment working end-to-end, but I'm running into a couple of edge cases with the current design:

• if a customer abandons while waiting in queue, the ticket gets created but is not assigned to anyone
• if an agent does not answer and the call reroutes, the ticket still gets created and gets assigned to first agent who missed the call.

I'm looking at two options:

Option 1 – Workflow-based

I'm planning to use a trigger/workflow and identify the final agent who handled the interaction before creating and assigning the incident.

The idea is to call the Conversation API, filter participants where purpose="agent" and the message state is connected, return the matching agent list, and then take the last agent using:

GetAt(agentNames, Count(agentNames) - 1)

At the moment this is more of a design idea I'm exploring, so I'd be interested to know whether this is a reliable pattern, and also whether there is a better API/event to identify when an agent is actually fully connected to the interaction.

Option 2 – Agent Script button

Alternatively, I'm thinking of moving this into an Agent Script button, where the agent clicks once connected and the process runs from there. My understanding is that Scripts can execute data actions, custom script actions can chain multiple steps, and Function data actions can also be called from Scripts. So the idea would be something like: JWT → People Lookup → create incident → assign incident.

Just wanted to ask:

• Has anyone implemented either of these approaches successfully?
• Is using the last connected agent from the Conversation API a reliable pattern?
• Is there a better way to detect when the agent is truly connected?
• Can this be done cleanly from Agent Script buttons using data actions or function data actions.

Would appreciate any advice or real-world experience.

#ArchitectandDesign

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

Hi Phaneendra, 

Yes, you're correct - in transfer scenarios, each agent involved will trigger their own ACW event, which could potentially create multiple tickets.

The simple solution: Add a check at the beginning of your workflow to see if a ticket has already been created for that conversation. You can do this by setting a flag/attribute/participant data on the conversation after the first ticket is created.

So the logic becomes:

1. Check: Has a ticket already been created for this conversation?
   1. If yes - stop, don't create another one
   2. If no - create the ticket and mark it as created

This ensures only one ticket gets created, and it will be assigned to the last agent who handled the interaction (since their ACW happens last).

You could of course look at different ways to track and trigger this however sometimes simplicity is best. 

Hi Josh,

Thank you, this is really helpful and makes a lot of sense especially using ACW to ensure the ticket is only created when an agent actually handles the interaction.

Just a quick follow-up question: in scenarios like transfers or callbacks, is there a possibility of multiple agents being involved and therefore multiple ACW events for the same conversation?

If so, would you recommend handling this with a safeguard (e.g. checking if a ticket is already created) or is there a better way to ensure the ticket is only created once and assigned to the correct final agent?

Thanks again for the guidance!

Hi @Phaneendra Avatapalli

I'd recommend going with your workflow-based approach with one simple adjustment.

The key: Wait to create the ticket until after the agent completes their wrap-up work. This naturally solves both issues you're running into:

• If a customer abandons while waiting > no agent wrap-up happens > no ticket gets created
• If an agent doesn't answer > no wrap-up happens > no ticket gets created
• Only interactions where an agent actually helped the customer will create tickets

For finding the right agent: Your idea to identify the last agent who was connected to the call is the right approach. Just make sure you're filtering for agents who actually answered (not just received an alert). This will handle transfer scenarios correctly too.

On the Script button idea: While it's doable, it relies on agents remembering to click the button every time, which can lead to inconsistency. The automated workflow is more reliable and is actually a better approach for these types of integrations.

Hope this helps you with your decision.

Hi everyone,

I'm currently working on a Genesys Cloud + BMC Helix integration for incident creation and assignment, and wanted to sanity check the best approach.

I've got incident creation and assignment working end-to-end, but I'm running into a couple of edge cases with the current design:

• if a customer abandons while waiting in queue, the ticket gets created but is not assigned to anyone
• if an agent does not answer and the call reroutes, the ticket still gets created and gets assigned to first agent who missed the call.

I'm looking at two options:

Option 1 – Workflow-based

I'm planning to use a trigger/workflow and identify the final agent who handled the interaction before creating and assigning the incident.

The idea is to call the Conversation API, filter participants where purpose="agent" and the message state is connected, return the matching agent list, and then take the last agent using:

GetAt(agentNames, Count(agentNames) - 1)

At the moment this is more of a design idea I'm exploring, so I'd be interested to know whether this is a reliable pattern, and also whether there is a better API/event to identify when an agent is actually fully connected to the interaction.

Option 2 – Agent Script button

Alternatively, I'm thinking of moving this into an Agent Script button, where the agent clicks once connected and the process runs from there. My understanding is that Scripts can execute data actions, custom script actions can chain multiple steps, and Function data actions can also be called from Scripts. So the idea would be something like: JWT → People Lookup → create incident → assign incident.

Just wanted to ask:

• Has anyone implemented either of these approaches successfully?
• Is using the last connected agent from the Conversation API a reliable pattern?
• Is there a better way to detect when the agent is truly connected?
• Can this be done cleanly from Agent Script buttons using data actions or function data actions.

Would appreciate any advice or real-world experience.

#ArchitectandDesign

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

Hi Josh,

Just wanted to clarify one point so I make sure I'm implementing it the right way.

When you say to wait until after the agent completes their wrap-up work, are you recommending the ACW trigger:

v2.detail.events.conversation.{id}.acw

or the wrap-up trigger:

v2.detail.events.conversation.{id}.wrapup?

The reason I'm asking is that our queue has ACW configured, and I just want to confirm whether ticket creation should happen when the interaction enters ACW, or only after the wrap-up work is fully completed.

Also, on the duplicate check, since the ticket creation would happen inside the workflow after ACW, were you referring to using Set Conversation Data in the workflow to store something like bmcTicketCreated = true after the first ticket is created?

I'm asking because in the workflow we can read conversation data, but we don't use Set Participant Data there the same way we do in the inbound call flow.

Thanks again.

Hi Phaneendra, 

For the trigger this is completely dependant on the use case :

1. For v2.detail.events.conversation.{id}.acw, this fires immediately after disconnect before the agent submits wrap-up. Use this if you want tickets created right away, even if agents abandon wrap-up.
2. For v2.detail.events.conversation.{id}.wrapup, this fires when the agent actually submits their wrap-up code. Use this if you only want tickets for completed interactions and need the wrap-up code data in your ticket.

Duplication Check - I would to use Get Conversation Data to check for a "bmcTicketCreated" flag at the start of your workflow. If found, exit immediately. If not found, create the ticket then use Set Conversation Data to set the flag. This approach requires no API calls and uses only native Architect actions. In transfer scenarios, the first agent sets the flag and subsequent agents find it and exit.

There is an edge case whereby using the wrapup trigger: Agent 1 may not wrap up before Agent 2 in the event of a blind transfer i.e. if Agent 1 has a number of actions to complete in ACW. This could result on the ticket being created from Agent 2's wrap up however once Agent 1 wraps up it would perform the duplication check. 

Personally I would use the wrapup trigger as this is likely to fit better for you, it can be changed later if you find it is not performing as you would like. 

Hi Josh,

Just wanted to clarify one point so I make sure I'm implementing it the right way.

When you say to wait until after the agent completes their wrap-up work, are you recommending the ACW trigger:

v2.detail.events.conversation.{id}.acw

or the wrap-up trigger:

v2.detail.events.conversation.{id}.wrapup?

The reason I'm asking is that our queue has ACW configured, and I just want to confirm whether ticket creation should happen when the interaction enters ACW, or only after the wrap-up work is fully completed.

Also, on the duplicate check, since the ticket creation would happen inside the workflow after ACW, were you referring to using Set Conversation Data in the workflow to store something like bmcTicketCreated = true after the first ticket is created?

I'm asking because in the workflow we can read conversation data, but we don't use Set Participant Data there the same way we do in the inbound call flow.

Thanks again.

Hi everyone,

I'm currently working on a Genesys Cloud + BMC Helix integration for incident creation and assignment, and wanted to sanity check the best approach.

I've got incident creation and assignment working end-to-end, but I'm running into a couple of edge cases with the current design:

• if a customer abandons while waiting in queue, the ticket gets created but is not assigned to anyone
• if an agent does not answer and the call reroutes, the ticket still gets created and gets assigned to first agent who missed the call.

I'm looking at two options:

Option 1 – Workflow-based

I'm planning to use a trigger/workflow and identify the final agent who handled the interaction before creating and assigning the incident.

The idea is to call the Conversation API, filter participants where purpose="agent" and the message state is connected, return the matching agent list, and then take the last agent using:

GetAt(agentNames, Count(agentNames) - 1)

At the moment this is more of a design idea I'm exploring, so I'd be interested to know whether this is a reliable pattern, and also whether there is a better API/event to identify when an agent is actually fully connected to the interaction.

Option 2 – Agent Script button

Alternatively, I'm thinking of moving this into an Agent Script button, where the agent clicks once connected and the process runs from there. My understanding is that Scripts can execute data actions, custom script actions can chain multiple steps, and Function data actions can also be called from Scripts. So the idea would be something like: JWT → People Lookup → create incident → assign incident.

Just wanted to ask:

• Has anyone implemented either of these approaches successfully?
• Is using the last connected agent from the Conversation API a reliable pattern?
• Is there a better way to detect when the agent is truly connected?
• Can this be done cleanly from Agent Script buttons using data actions or function data actions.

Would appreciate any advice or real-world experience.

#ArchitectandDesign

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

Hi Phaneendra

I agree with Josh, leaving script is bad because it will depend on the agent clicking, or even if you put it on the homepage to make it automatic, it will still depend on the agent to open the script. So in your scenario, a trigger is best.

Hi everyone,

I'm currently working on a Genesys Cloud + BMC Helix integration for incident creation and assignment, and wanted to sanity check the best approach.

I've got incident creation and assignment working end-to-end, but I'm running into a couple of edge cases with the current design:

• if a customer abandons while waiting in queue, the ticket gets created but is not assigned to anyone
• if an agent does not answer and the call reroutes, the ticket still gets created and gets assigned to first agent who missed the call.

I'm looking at two options:

Option 1 – Workflow-based

I'm planning to use a trigger/workflow and identify the final agent who handled the interaction before creating and assigning the incident.

The idea is to call the Conversation API, filter participants where purpose="agent" and the message state is connected, return the matching agent list, and then take the last agent using:

GetAt(agentNames, Count(agentNames) - 1)

At the moment this is more of a design idea I'm exploring, so I'd be interested to know whether this is a reliable pattern, and also whether there is a better API/event to identify when an agent is actually fully connected to the interaction.

Option 2 – Agent Script button

Alternatively, I'm thinking of moving this into an Agent Script button, where the agent clicks once connected and the process runs from there. My understanding is that Scripts can execute data actions, custom script actions can chain multiple steps, and Function data actions can also be called from Scripts. So the idea would be something like: JWT → People Lookup → create incident → assign incident.

Just wanted to ask:

• Has anyone implemented either of these approaches successfully?
• Is using the last connected agent from the Conversation API a reliable pattern?
• Is there a better way to detect when the agent is truly connected?
• Can this be done cleanly from Agent Script buttons using data actions or function data actions.

Would appreciate any advice or real-world experience.

#ArchitectandDesign

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