Capturing the "Agent Connected" Event in Open Messaging

To detect when an agent has been assigned to an interaction in Genesys via Open Messaging, the following event is used:

    v2.detail.events.conversation.{id}.user.start

This event is triggered by the system when a queue assigns an interaction to an agent, and it reaches the ringing stage in the agent's interface.

Use Cases

There are two distinct scenarios depending on the agent's configuration:

1. Agent with AutoAnswer enabled

   Description: The interaction is automatically answered by the system as soon as it is presented to the agent.

   Event behavior: The user.start event is considered valid, as it guarantees that the agent is connected to the session.

   Result: The event is registered as Agent Connected without requiring additional validation.

2. Agent with manual answer

   Description: The agent must manually accept the interaction when it is presented.

   Event behavior: Although the user.start event is triggered during the ringing stage, it does not guarantee that the agent has answered the interaction.

   Additional validation: A follow-up check is implemented in the flow to confirm whether the agent has indeed answered, preventing false positives.

In both use cases, two actions are required: one to query the agent's information and another to send the event to Lynn, so the customer can receive the agent connection message.

Capturing and Sending the "Agent Connected" Event from Genesys to Lynn

Below are the components required to implement this functionality within the Genesys Cloud environment.

Configured components:

Component	Description
[Actions] Query Agent	Retrieves the agent's information from Genesys.
[Actions] Send event to Lynn	Sends structured data to Lynn via HTTP POST.
[Trigger]	Captures the user.start event from Genesys.
[Workflow]	Processes and sends the event based on the detected scenario.

[Actions] Query Agent Information

This action retrieves user information at the time the event is generated. It queries the userId received from the event and returns a JSON object as a string, which is later parsed in the flow to extract the agent's name and active sessions.

Integration: Genesys Cloud Data Actions

Contract

Input: userID (string)
Output: result (string)

Configuration

Method: GET
Endpoint: /api/v2/analytics/agents/${input.userId}/status
Response:

    {
        "translationMap": {},
        "translationMapDefaults": {},
        "successTemplate": 
            {
                "result": "$esc.jsonString(${rawResult})"
            }
    }

Note

This action requires the Analytics → AgentState → View permission. Therefore, the associated integration must be authorized to execute this API.

[Actions]: Send the event to Lynn (/PureCloud/OpenMessaging_OnEvent)

The purpose of this action is to send the event to Lynn using the configured endpoint. The request body (body) must be constructed using the object keys expected by the API.

Integration: Web Services Data Actions

Contract

Input: endpoint (string)
Input: body (string)

Configuration

Method: POST
Endpoint: ${input.endpoint}
Body: ${input.body}
Response:

    {
        "translationMap": {},
        "translationMapDefaults": {},
        "successTemplate": "${rawResult}"
    }

Scenario Where the Queue Has AutoAnswer Enabled

In this scenario, the queue has AutoAnswer enabled, so the interaction assigned to the agent is automatically answered. Therefore, the flow only needs to retrieve the agent's name.

The flow consists of the following components:

[CallDataActions] Used to invoke the action that retrieves the agent's information.

Input: Flow.userId (Expression)
Output: Flow.result (Expression)

[UpdateData]

Configured in the SUCCESS branch of the previous component. Its purpose is to process the service response and transform it into a JSON object (JsonObject).

Variable Name: Flow.JsonObject
Value To Assign: JsonParse(Flow.result)

[Call Data Actions] Used to invoke the service that sends the event to Lynn

Input endpoint (Literal): <<Here Base Url>>/PureCloud/OpenMessaging_OnEvent
Input body (Expression):

    { 
        "conversationId": "Flow.conversationId", 
        "userId": "Flow.userId", 
        "userName": "ToString(Flow.JsonObject.userName)",
        "type": "eventAgentConnect", 
        "provider": "Flow.provider" , 
        "externalId": "Flow.addressTo"
    }

Note

En el campo endpoint, se debe reemplazar Aquí Base Url por la base URL recomendada por Lynn. Esta URL se define al configurar el módulo de extensión para transferencias, y su valor es dinámico: Lynn selecciona automáticamente la mejor opción según la región de Genesys.

Functionality summary::

In the ideal case, when AutoAnswer is configured, the system first retrieves the agent’s name. This information is then sent to Lynn as a dynamically built JSON string.

It is important to respect the defined KEYs, since Lynn expects these values in order to correctly process the information.

[Workflow] Advanced — recommended for cases where the agent manually answers the interactions.

When the event triggers the flow, the system waits a reasonable amount of time to allow the agent to respond. Next, a service is called to obtain the agent’s current status.

This status is evaluated within a loop, as the agent may be handling multiple interactions simultaneously. In each iteration, the system checks whether the corresponding conversationId is present and being handled. Only when this condition is met is the event sent to Lynn.

The flow would be represented as shown in the following image.

Components applicable to this use case:

• [Loop] Bucle

  

  Current Index: Flow.count
  Maxi Loop Count: ToInt(Flow.JsonObject.sessionCount)

• [Decision] to check if the interaction is active.

  Expression (Expression):

        ToString(Flow.JsonObject.sessions[Flow.count].conversationId) == Flow.conversationId AND ToString(Flow.JsonObject.sessions[Flow.count].segmentType) == "interact"
  

  

  Important

  This second solution can be adapted to offer greater flexibility in execution times by using shorter delay intervals and retrying in cases where the agent has not yet answered.

• [TRIGGER] Agent Connected

  A trigger is created for the event v2.detail.events.conversation.{id}.user.start.
  It is recommended to apply filters associated with the queueId of the relevant queues to avoid sending unwanted events.
  This trigger redirects to the previously created workflow.

  

  Note

  Make sure to activate the trigger so that events are processed correctly.