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.

Resumen del funcionamiento:

En el caso ideal, cuando está configurado el AutoAnswer, lo primero que hace el sistema es recuperar el nombre del ejecutivo. Luego, se envía esta información a Lynn en un string con formato JSON, el cual se construye dinámicamente.

Es importante respetar las claves (KEYs) definidas, ya que son los valores esperados por Lynn para procesar correctamente la información.

[Workflow] Avanzado, este es sugerido para los casos donde el Agente contesta Manualmente las interacciones.

Cuando el evento activa el flujo, se espera un tiempo prudente para permitir que el agente responda. A continuación, se invoca un servicio que obtiene el estado actual del agente.

Este estado se evalúa dentro de un bucle, ya que el agente podría estar gestionando múltiples interacciones simultáneamente. En cada iteración, se verifica si el conversationId correspondiente está presente y siendo atendido. Solo cuando esta condición se cumple, se envía el evento a Lynn.

El flujo se representaría como en la siguiente imagen.

Componentes que aplican a este caso de uso:

[Loop] Bucle

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

[Decision] para Evaluar si la interacción esta activa

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.