Forum Discussion
callRecord.id no longer matches call.callChainId — how to link live calls to call records?
I’m tracking information about live Teams meetings while they’re in progress. Each live meeting (call) has a call.id that I use to uniquely identify and store data in my database.
Once the call ends, I query the communications/callRecords endpoint to retrieve metadata about that call. My expectation was to use some stable identifier to link the live call to its corresponding call record, but this is where things break down.
Previously, I found that call.callChainId from the live call object matched the callRecord.id from the callRecords endpoint. That made it really easy to link the two.
But recently, this seems to have changed — the callRecord.id is now different from both the call.id and the call.callChainId, making it impossible to reliably connect my in-call data with the post-call metadata.
What I’m trying to figure out:
- Is there any stable property in the live call object (besides id or callChainId) that also shows up in the callRecord so I can match them?
- Meeting URL doesn’t work for my use case because it’s the same for recurring meetings.
- I’m already listening for call record change notifications and processing them — the issue is linking them back to the original live call I tracked.
Any guidance on this would be super helpful. Has the meaning or behavior of callChainId changed recently? Is there another identifier I can depend on?
Thanks!
3 Replies
Sayali-MSFTMicrosoft
Hello Hello daraA, You’re correct: the behavior changed recently, and what used to work (matching call.callChainId from the live call to callRecord.id) no longer holds.- Previously: callRecord.id often matched the callChainId from the live call object, so you could link them easily.
- Now: callRecord.id is its own unique identifier and does not equal callChainId or call.id. This is by design; the API team decoupled these IDs as part of recent updates to the callRecords API.
Is there a stable property you can use?
1. callChainId still exists in both the live call and the call record, but it’s no longer the primary key. Instead, it’s now intended as a correlation identifier for related calls (e.g., transfers, consults, or meetings with multiple legs).
2. The callRecord resource includes id (unique per record) and still exposes callChainId for grouping. So you can:
Capture call.callChainId during the live call.
When you receive a callRecord notification or query /communications/callRecords, filter or match on callChainId instead of id.
Reference Document-
1.callRecord resource type - Microsoft Graph v1.0 | Microsoft Learn
2.Microsoft Graph Call Records API FAQ - Microsoft Graph | Microsoft Learn - callChainId is not guaranteed to be globally unique—it’s unique per chain of related calls, not per individual call leg. If you only need to link “this live call session” to its record, and you know there’s no transfer/merge scenario, it’s safe enough.
- If you need absolute uniqueness, you’ll have to maintain your own mapping table keyed by call.id → callChainId → callRecord.id once the record arrives.
- Meeting URL (joinWebUrl) is unreliable for recurring meetings, as you noted.
Thanks for the reply. In my experience, callChainId does not exist in the callRecord (unless it is equal to the call Record Id which I can't be sure is the case). If it's supposed to, what property is it stored as in the callRecord? Is there a correlation identifier in the callRecord, I also have not seen a property named this, is it called something other than correlationId?
I am currently capture call.Id and call.callChainId during the call and mapping those in a table, since I have access to neither once I do receive my callRecord change notification, I am not able to then map it to the callRecord. You mentioned filtering on callChainId, how would I go about this?
- Sayali-MSFT
Hello daraA,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.
