Excited to share our progress on the Microsoft Teams integration project. We are configuring Direct Routing through PowerShell scripts and setting up SBC parameters via the Teams Admin Center. The goal involves pushing call session data to a custom Azure Function using Genesys Cloud Data Actions. We subscribed to the call.session event type for both voice and chat interactions. During testing inbound PSTN calls return a valid conversationId within the JSON payload sent to the webhook endpoint. However when initiating a Web Chat session the conversationId field appears null in the transmitted data.
Here is the snippet showing the difference:
{
"eventType": "call.session",
"conversationId": null,
"id": "12345"
}
This prevents our Teams bot logic from correlating messages correctly. Environment is AWS US-East-1 on Genesys Cloud release 2403. Data Action configuration uses standard HTTP POST with bearer token authentication. Anyone encountered this specific behavior difference between voice and chat event types?
The null value occurs because web chat sessions do not generate a conversationId in the same format as PSTN calls immediately upon initiation. Salesforce integration managed packages handle this by checking the conversationType field before parsing identifiers. If you need the ID for screen pops ensure your Data Action payload includes the id field which represents the call or session unique identifier regardless of type. Check the API documentation for the /api/v2/conversations endpoint to see how the ID maps in chat scenarios versus voice.
The response structure often looks like this:
{
"conversationId": "chat-session-uuid",
"id": "call-id-string"
}
This causes issues when building Apex wrappers for external CRM lookups.
Migrating Zendesk workflows to Genesys Cloud often reveals this mapping discrepancy. Zendesk tickets always contain an internal ID while GC relies on conversationId for thread correlation in chat. In a migration context map the conversationId field to your external ticket reference variable. If using REST API directly verify the conversationId structure matches what your downstream system expects.
Sometimes adding a custom attribute in the Data Action payload helps bridge the gap between legacy workflows and new session logic.