Genesys Cloud - Developer Community!

Has anyone successfully implemented participant correlation logic for complex conversation flows?

I'm working on an application that needs to understand conversation flow and participant relationships. Specifically, I need to trace the sequence of interactions between participants to reconstruct conversation timelines from both the notifications API and analytics API data. We use the notifications data to build up the call state as each notifications come in, and then every 15 minutes we do a sync with the /api/v2/analytics/conversations/details/query endpoint to finalize the state. The schema for each data source is viewable here:

Notification Topic: https://developer.genesys.cloud/notificationsalerts/notifications/available-topics#v2-routing-queues--id--conversations
Analytics API Endpoint: https://developer.genesys.cloud/devapps/api-explorer#post-api-v2-analytics-conversations-details-query

I need to reliably link ACD participants with agent participants to understand the flow: ACD Queue → Agent
Our current approach using peerId fields fails in complex scenarios such as with call merges. Looking at the API responses, many peerId values are null, orphaned, or don't create clear relationships between the ACD and agent sessions.

I have linked an example JSON file at Event JSON - Pastebin.com that is structured as follows:

{
  "conversations": {
    "conversation-1": {
      ... conversation data retrieved from /api/v2/analytics/conversations/details/query after the notifications below were processed
    },
    "conversation-2": {
      ... conversation data retrieved from /api/v2/analytics/conversations/details/query after the notifications below were processed
    }
  },
  "notifications": {
    "conversation-1": {
      ... most recent notification received related to the call "conversation-1"
    },
    "conversation-2": {
      ... most recent notification received related to the call "conversation-2"
    }
  }
}

This JSON file represents a call scenario where a customer call is transferred between two agents and then merged with an internal conference call before the conference is picked up by a third agent:

Conversation ID: conversation-1
2025-06-02T12:13:00.81Z - Customer call is created and routed through several IVRs.
2025-06-02T12:15:24.671Z - Customer call is routed through TEST_QUEUE_1 ACD queue.
2025-06-02T12:15:25.128Z - Customer call is routed to agent alice.
2025-06-02T12:17:28.467Z - Agent alice performs a blind transfer to an IVR.
2025-06-02T12:17:31.624Z - Customer call is routed through TEST_QUEUE_2 ACD queue.
2025-06-02T12:17:54.715Z - Agent alice wraps up initial call.
2025-06-02T12:22:26.558Z - Customer call is routed to agent bob.
2025-06-02T12:32:36.536Z - Customer call is merged into conversation-2.
2025-06-02T12:32:39.011Z - Agent bob wraps up call after merge.

Conversation ID: conversation-2
2025-06-02T12:26:10.388Z - Agent bob initiates an internal call to an IVR.
2025-06-02T12:26:13.19Z - Internal call is routed through TEST_QUEUE_3 ACD queue.
2025-06-02T12:32:36.536Z - Customer call conversation-1 is merged in.
2025-06-02T12:37:31.569Z - Merged call is routed to agent charlie.
2025-06-02T12:42:02.544Z - Call is completed with no wrap-up.

From this sequence of events, I would expect to see three discrete call flows:
Call 1 - Queued in TEST_QUEUE_1 at 2025-06-02T12:15:24.671Z, Answered by agent alice at 2025-06-02T12:15:25.128Z, Completed wrap-up at 2025-06-02T12:17:54.715Z
Call 2 - Queued in TEST_QUEUE_2 at 2025-06-02T12:17:31.624Z, Answered by agent bob at 2025-06-02T12:22:26.558Z, Completed wrap-up at 2025-06-02T12:32:39.011Z
Call 3 - Queued in TEST_QUEUE_3 at 2025-06-02T12:26:13.19Z, Answered by agent charlie at 2025-06-02T12:37:31.569Z, Completed no wrap-up 2025-06-02T12:42:02.544Z

What we need to know is the recommended approach for linking participant interactions/sessions in the event data so that we can associate the agent leg of the call to the ACD leg, and identifying when such an association exists. Previously, we were using the peerId field on interactions to identify mutual peer relationships between the ACD and the agent, however this approach fails the given example. For instance, the final agent leg for agent charlie references a peerID of "orphaned-session" which is not connected to any other leg in the call. Also, the peerIds for most of the sessions for the second conversation in the analytics API response are null and do not match the peerIds of what we received in the notifications. The only other possible methods of linking the sessions we can see are through the queueID and the temporal sequence of events, although we're not certain if these relationships can be relied upon.

SPECIFIC QUESTIONS:
What is the recommended approach for matching ACD participants to agent participants?
What fields from the API event schema should we be using?
Is the temporal sequence of events a reliable method to associate?
Do we need to pay attention to the way the ACD leg disconnected (disconnectType)?
Are there specific ID fields that create explicit relationships?
Should correlation logic be identical between notifications API and analytics API data? If not, how do they differ?
Are there different APIs that we should be using?
How should we handle/identify edge cases?
- Cancelled transfers (ACD participant never connects to agent)
- Direct agent transfers that bypass the ACD
- Calls that are routed elsewhere after passing through the ACD before reaching an agent
- Abandoned calls.
- Any others you can think of?

Huge thanks in advance to anyone willing to dig into this complex example. This correlation logic is foundational to our application, so any insights from the community would be incredibly valuable!