Hi Carlos,
In addition to Dominik's recommendations, I'd suggest designing your integration so that it doesn't assume transcription availability for every conversation.
Even when voice transcription is enabled at the organization and queue level, there can be scenarios where transcripts are not produced or may start later in the interaction, for example:
- Recording is disabled because the caller declined consent.
- Recording is paused/resumed during the call.
- The conversation is transferred to a flow, queue, or segment with different recording settings.
- Transcription services experience delays and transcript events arrive asynchronously.
Because of this, I would recommend that your Embeddable Framework application:
- Subscribe to the conversation/transcription notification topics.
- Detect dynamically whether transcript events are being published.
- Gracefully handle "no transcript available" scenarios in the UI rather than assuming they will always exist.
Another best practice is to use the same consent outcome that drives the Enable Participant Recording action as metadata for downstream systems. Whether that's participant data, conversation attributes, or an external audit system, it gives you a way to demonstrate why transcripts are or are not available for a particular interaction.
From a compliance perspective, this is often more valuable than simply checking whether transcript events exist.
Also, if you're exposing live transcripts to end users, consider displaying an indicator such as:
- "Live transcription active"
- "Awaiting transcription"
- "Transcription unavailable (recording not enabled)"
This tends to reduce confusion when agents or supervisors expect transcript content but recording consent was never granted.
I'd be interested to hear from others whether they've seen any lag or ordering considerations with the Voice Transcription notification topics in high-volume environments.
------------------------------
Cesar
INDRA COLOMBIA
------------------------------