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.

------------------------------
Josh Coyle
Senior Professional Services 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!

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

Original Message:
Sent: 04-10-2026 06:44
From: Josh Coyle
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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.

------------------------------
Josh Coyle
Senior Professional Services 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. 

------------------------------
Josh Coyle
Senior Professional Services Consultant
------------------------------

Original Message:
Sent: 04-10-2026 07:36
From: Phaneendra Avatapalli
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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!

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


Original Message:
Sent: 04-10-2026 06:44
From: Josh Coyle
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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.

------------------------------
Josh Coyle
Senior Professional Services Consultant

Thank you @Josh Coyle, that makes perfect sense.

Using ACW to create the ticket only after the interaction is actually handled feels like the cleanest approach, and the duplicate check also sounds like a simple way to handle transfer scenarios.

Really appreciate the guidance.

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

Original Message:
Sent: 04-10-2026 08:35
From: Josh Coyle
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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. 

------------------------------
Josh Coyle
Senior Professional Services Consultant
------------------------------


Original Message:
Sent: 04-10-2026 07:36
From: Phaneendra Avatapalli
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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!

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


Original Message:
Sent: 04-10-2026 06:44
From: Josh Coyle
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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.

------------------------------
Josh Coyle
Senior Professional Services 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. 

------------------------------
Josh Coyle
Senior Professional Services Consultant
------------------------------

Original Message:
Sent: 04-10-2026 10:42
From: Phaneendra Avatapalli
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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 Josh,

Thank you, this is really helpful.

That makes sense, and the duplicate check using Get Conversation Data plus Set Conversation Data sounds like a clean way to handle the transfer scenario without needing any extra API calls.

For our environment, I think we'll likely go with the ACW trigger rather than wrapup, mainly because we do not currently use wrap-up codes/process consistently, so ACW feels like the more practical and reliable event for us.

We'll keep the duplicate protection using bmcTicketCreated, and operationally we'll also keep the rule of no blind transfers between agents. If a warm transfer happens, the transferring agent will assign the existing ticket to the receiving agent as part of the handoff.

Thanks again for the guidance this has been really useful.

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

Original Message:
Sent: 04-10-2026 11:31
From: Josh Coyle
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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. 

------------------------------
Josh Coyle
Senior Professional Services Consultant
------------------------------


Original Message:
Sent: 04-10-2026 10:42
From: Phaneendra Avatapalli
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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

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.

------------------------------
Kaio Oliveira
GCP - GCQM - GCS - GCA - GCD - GCO - GPE & GPR - GCWM

PS.: I apologize if there are any mistakes in my English; my primary language is Portuguese-Br.
------------------------------

Thank you @Kaio Oliveira, this is really helpful.

That makes sense, especially around avoiding reliance on the agent opening or clicking within the script. The trigger/workflow approach does sound more reliable for this use case.

Also really helpful to see your Conversation API pattern for retrieving the last agent. That lines up closely with what I was thinking as well, especially for reroute or transfer scenarios.

At the moment I'm leaning towards testing this with an ACW-based trigger so the ticket is only created after the interaction is actually handled, and then using the last agent from the conversation to assign it correctly.

Thanks again for sharing the configuration.

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

Original Message:
Sent: 04-10-2026 08:21
From: Kaio Oliveira
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

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.

We experienced this during our Salesforce implementation.

 

The interaction was alert for the agent who didn't respond, and they became the case owner, even though they weren't to attend.

We didn't fix this through Genesys the customer fixed it through Salesforce.

 

When the interaction reaches the agent, in order for them to continue the service (Salesforce), they need to click "assign to me," otherwise the fields won't be available to them.

 

This way, the agent can't "forget" to attend to them.

Now, if I need to fixed by Genesys, I would certainly use the trigger.

Regarding the API for retrieving the last agent, I use it in another scenario (satisfaction survey) and it works very well.

see the configurations:

Contracts

Input: 

{

  "type": "object",

  "additionalProperties": true,

  "properties": {

    "conversationId": {

      "type": "string"

    }

  }

}

output

{

  "type": "object",

  "additionalProperties": true,

  "properties": {

    "userId": {

      "type": "array",

      "items": {

        "type": "string",

        "title": "Item 1"

      }

    }

  }

}

HTTP Method - GET

endpoint /api/v2/conversations/${input.ConversationID}

response: 

{

  "translationMap": {

    "userId": "$.participants[?(@.purpose == 'agent')].userId"

  },

  "translationMapDefaults": {

    "userId": "[\"Not Found\"]"

  },

  "successTemplate": "{\"userId\" : ${userId}}}"

}

in the architect

after data action ----

update data - flow.lastAgent - value = If(Count(Flow.UserList) > 0, Flow.UserList[Count(Flow.UserList) - 1], "")

------------------------------
Kaio Oliveira
GCP - GCQM - GCS - GCA - GCD - GCO - GPE & GPR - GCWM

PS.: I apologize if there are any mistakes in my English; my primary language is Portuguese-Br.
------------------------------

------------------------------
Suryavesh Sahani
------------------------------

Hi Suryavesh,

Thank you for your input you're actually the first person I've come across who is working with BMC Helix. I've built a script‑based approach where the agent clicks a button, which then creates a ticket and opens the ticket URL in a new window. Based on your suggestion, I'm sure it will be possible to hide the "Create Ticket" button after a successful creation using a custom action I'll give that a try, so thank you for the insight.

I'm keeping everything script‑based for now because using a trigger or workflow ends up creating duplicate or unassigned tickets, which makes it much harder to manage.

The ID Number is passed in from the IVR, and if it's missing or incorrect, I've added an input field that feeds into the function to create and assign the ticket. Everything from generating the JWT through to assignment is handled within a single function in the script.

Have you also worked with the knowledge‑side integration? I've done a minimal setup where I export all BMC Helix knowledge articles into a Google Sheet as direct links. I'd be interested to hear whether you've implemented anything more advanced on the knowledge side.

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

Original Message:
Sent: 04-10-2026 12:02
From: Suryavesh Sahani
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

We've already built the core flow for creating and assigning incidents between Genesys Cloud and BMC Helix. Everything works technically.. When I started testing real-world call scenarios some gaps showed up:

 

* If a customer abandons in queue an incident still gets. Has no agent assigned to it.

 

* If an agent doesn't answer and the call reroutes the incident still gets. Ends up assigned to the first agent who missed the call, which is wrong.

 

These edge cases make it clear I need a way to determine who actually handled the interaction not just who was offered the call.

 

So I'm looking at two approaches.

 

### Option 1. Workflow-Based

 

My idea is to let the interaction finish use a trigger/workflow to:

 

* Pull conversation details via the Conversation API.

 

* Filter participants where:

 

* purpose = "agent"

 

* state = "connected"

 

* Collect all agents who were truly connected.

 

* Take the connected agent.

 

I think this pattern is commonly used in Genesys workflows. The " connected agent" logic is generally reliable because Genesys logs every state transition.

 

The key is filtering for actual connection not alerting or ringing.

 

I still need to find out if there's a precise event that fires only when the agent is fully connected.

 

I like this approach because:

 

* It's fully automated.

 

* No agent involvement is needed.

 

* It scales well. Avoids human error.

 

I need to watch out for:

 

* Timing. The workflow must run after the agent is truly connected.

 

* Transfers or conferences may add complexity.

 

### Option 2. Agent Script Button

 

The other approach is to shift the trigger to the agent.

 

Once they're connected they click a button in the script that runs:

 

* JWT generation

 

* People lookup

 

* Incident creation

 

* Incident assignment

 

I think it's simple and avoids the " agent" issue entirely because the agent triggers it only when they're actually handling the call.

 

It introduces human dependency. Agents may forget, click too early or click multiple times.

 

I like this approach because:

 

* It's very accurate.

 

* Easy to control and troubleshoot.

 

* No need to parse conversation logs.

 

The downside is:

 

* It relies on agent behavior.

 

* Not ideal, for high-volume environments.

------------------------------
Suryavesh Sahani
------------------------------

Hi Suryavesh,

Thank you for raising that point about agents accidentally clicking the button multiple times. That was a really good callout, and I ended up implementing a guard rail in the script to prevent duplicate ticket creation.

What I did was hide the Create BMC Ticket button after a successful ticket creation.

I used a Basic True/False script variable:
BmcTicketCreated with default value: false

Then, in the success branch of the custom action, once the BMC ticket was created successfully, I set: BmcTicketCreated = true

After that, I used this visibility expression on the Create BMC Ticket button:

(
  {{Scripter.Interaction State}} == "Connected" or
  {{Scripter.Interaction State}} == "Disconnected" or
  {{Scripter.Interaction State}} == "Held"
)
and
({{BmcTicketCreated}} == {{FalseValue}})

I also used helper boolean variables as Basic True/False variables:

• TrueValue = true
• FalseValue = false

With this setup, the button is available initially, but once the ticket is created successfully, it disappears, which prevents agents from clicking it again and creating another request by mistake.

Thanks again for the suggestion it was a very useful improvement to add.

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

Original Message:
Sent: 04-16-2026 09:53
From: Phaneendra Avatapalli
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

Hi Suryavesh,

Thank you for your input you're actually the first person I've come across who is working with BMC Helix. I've built a script‑based approach where the agent clicks a button, which then creates a ticket and opens the ticket URL in a new window. Based on your suggestion, I'm sure it will be possible to hide the "Create Ticket" button after a successful creation using a custom action I'll give that a try, so thank you for the insight.

I'm keeping everything script‑based for now because using a trigger or workflow ends up creating duplicate or unassigned tickets, which makes it much harder to manage.

The ID Number is passed in from the IVR, and if it's missing or incorrect, I've added an input field that feeds into the function to create and assign the ticket. Everything from generating the JWT through to assignment is handled within a single function in the script.

Have you also worked with the knowledge‑side integration? I've done a minimal setup where I export all BMC Helix knowledge articles into a Google Sheet as direct links. I'd be interested to hear whether you've implemented anything more advanced on the knowledge side.

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


Original Message:
Sent: 04-10-2026 12:02
From: Suryavesh Sahani
Subject: Best approach for assigning incidents to final agent (Workflow vs Script)?

We've already built the core flow for creating and assigning incidents between Genesys Cloud and BMC Helix. Everything works technically.. When I started testing real-world call scenarios some gaps showed up:

 

* If a customer abandons in queue an incident still gets. Has no agent assigned to it.

 

* If an agent doesn't answer and the call reroutes the incident still gets. Ends up assigned to the first agent who missed the call, which is wrong.

 

These edge cases make it clear I need a way to determine who actually handled the interaction not just who was offered the call.

 

So I'm looking at two approaches.

 

### Option 1. Workflow-Based

 

My idea is to let the interaction finish use a trigger/workflow to:

 

* Pull conversation details via the Conversation API.

 

* Filter participants where:

 

* purpose = "agent"

 

* state = "connected"

 

* Collect all agents who were truly connected.

 

* Take the connected agent.

 

I think this pattern is commonly used in Genesys workflows. The " connected agent" logic is generally reliable because Genesys logs every state transition.

 

The key is filtering for actual connection not alerting or ringing.

 

I still need to find out if there's a precise event that fires only when the agent is fully connected.

 

I like this approach because:

 

* It's fully automated.

 

* No agent involvement is needed.

 

* It scales well. Avoids human error.

 

I need to watch out for:

 

* Timing. The workflow must run after the agent is truly connected.

 

* Transfers or conferences may add complexity.

 

### Option 2. Agent Script Button

 

The other approach is to shift the trigger to the agent.

 

Once they're connected they click a button in the script that runs:

 

* JWT generation

 

* People lookup

 

* Incident creation

 

* Incident assignment

 

I think it's simple and avoids the " agent" issue entirely because the agent triggers it only when they're actually handling the call.

 

It introduces human dependency. Agents may forget, click too early or click multiple times.

 

I like this approach because:

 

* It's very accurate.

 

* Easy to control and troubleshoot.

 

* No need to parse conversation logs.

 

The downside is:

 

* It relies on agent behavior.

 

* Not ideal, for high-volume environments.

------------------------------
Suryavesh Sahani