Voice

The Voice Trigger block lets users start a workflow by speaking. It records audio from the browser, transcribes it using your configured speech-to-text (STT) provider, and optionally retrieves relevant context from a knowledge base before the workflow continues.

Configuration

Recording studio settings

Open Config in the studio header to choose the transcription model and language and inspect Session health. Config remains accessible during recording and transcript review. Model and language settings become read-only once recording starts. The microphone selector remains beside Record on the initial screen.

Outputs

Once transcription and (optional) KB retrieval complete, the following variables are available in downstream blocks:

Replace voice1 with the name you assigned to the block.

Deployment

The Voice Trigger generates a shareable Trigger Link (format: /v/{id}) once the workflow is deployed. Share that link with users — opening it in a browser presents the voice recording interface and starts a workflow run when audio is submitted.

The recorder is a full recording studio built for real meetings: one desk carries preparation, live capture, and review, with the controls on a console bar. Recording can be paused and resumed, the screen stays awake while capture is live, and closing the tab mid-recording asks for confirmation. The live transcript occupies the main canvas. Open Notes, Speakers, Knowledge, or Conversation from the bottom toolbar when needed. Recording health details are under Config; an indicator highlights warnings. Notes ride into the workflow as <voice1.notes> and are saved to the process instance's knowledge base. Calm view shows a single recording timer and the latest speech on an open canvas. Working view shows the full live transcript with the timer in the bottom controls. After stopping you can correct the transcript before sending it — the edited text is what the workflow receives. Recordings up to four hours are supported.

How the live transcript is produced

Two paths, chosen by the model you bound to the block. Which one is running is shown under Config → Session health while you record.

A model that streams keeps a live session open with the provider for as long as you record. The provider decides where each phrase ends and returns text continuously.

A model that does not stream — Whisper and most batch transcription models — is called once per phrase. The browser detects where each phrase ends and sends that stretch of audio. Long speech is also bounded by a maximum request duration. Each transcribed phrase carries the time range it occupies in the recording. That range is what lets the transcript be laid out by speaker. Batch diarization labels apply only to the individual request. Browser speaker tracking is enabled by default and works alongside any STT vendor. It keeps one voice registry for the recording, including across pauses and transcription reconnects. Each new recording starts a fresh registry. Anyone heard by the microphone can receive an anonymous speaker label, including guests outside the organization; no account or voice enrollment is required. An organization can explicitly disable browser tracking in its voice settings. Request-local labels do not count as new people.

Both paths behave the same way in every respect that matters to you:

• Pausing closes the provider session and keeps everything already transcribed. Resuming re-opens it and continues below what is on screen. If your provider bills per session-hour, a break is not billed.
• Speech detection limits idle batch requests. The recording retains its original timing and silence; transcription windows may include surrounding context. Native streaming behavior depends on the selected provider.
• A stretch that could not be transcribed is marked, never hidden. If the provider rate-limits, fails, or falls too far behind — or the platform could not record the transcription for governance — the transcript shows a dashed rule with the reason and the time instead of appearing to be silence. The rule appears in both calm and working view, including before anything has been transcribed. Recording itself is unaffected — the audio is still captured and saved.
• Losing speech interrupts you. While phrases keep failing, a Live transcription is failing banner states how much speech has not been transcribed and since when. It clears as soon as a phrase transcribes again. Text withheld by a privacy policy is marked in the transcript but does not raise the banner — that is the policy working, not transcription failing.
• A transient failure does not end live transcription. A rate limit or a brief provider outage is retried, and the next phrase transcribes normally. If your model's deployment has a low per-minute request limit (Azure Whisper deployments default to 3 requests per minute), live transcription of continuous speech will keep hitting it; choose a model with more capacity or raise the deployment's quota.

Final transcript and speaker alignment

The final pass processes audio independently of speaker changes. A recording of up to two minutes stays in one request. Longer recordings use bounded sections with surrounding audio context. Word timestamps, when supplied by the selected model, assign overlapping words to one section before joining them to the recording's speaker timeline. Changing voices does not itself cut the audio.

Models that return only segment timings use coarser speaker alignment. Models without usable timestamps are transcribed on non-overlapping sections. Ambiguous speech remains unattributed, and a final transcript can still be produced when speaker tracking is unavailable. Transcription providers remain replaceable.

Live provisional text may change while settled text remains stable. The final pass produces a separate reviewable revision; review words and speaker assignments before approving it for the process flow. Completion does not guarantee accuracy.

When the provider rate-limits a section, the final pass waits — as long as the provider asks, and otherwise long enough to clear a per-minute limit — and retries that section, rather than giving up on the whole recording. A section that still fails after a few minutes of retries ends the pass as Authoritative transcript unavailable; the live transcript remains available to review and accept.

Download before approval

After stopping, choose Download recording beside playback to save the original audio. Download remains available while transcription is preparing or has failed; it does not approve the transcript or continue the process flow. Keep the review tab open until the download finishes. This button uses the audio held by that browser tab and is not available for a recording recovered after a page reload. Uploaded files retain their original filename; microphone recordings download as recording.webm without conversion.

Estimating transcription cost

For a Process Flow recording, budget for two separate uses of STT: live captions and the final pass after stopping. The selected provider bills the audio it processes according to its own rate and rounding rules. Speech detection can reduce live batch audio, but the final pass includes the original silence and surrounding context.

A useful estimate is: live audio hours × live rate + final-pass audio hours × final rate + billed retries. The final pass's current two-minute sections add about 3.3% context for a long recording. A two-hour recording therefore sends approximately 2.066 hours to the final pass, plus whatever audio was transcribed live. If usable timestamps are missing, additional non-overlapping requests can increase this total. Repeating the final pass also incurs new provider usage.

Browser speaker tracking has no separate cloud diarization request charge, but uses the recording device's compute. Storage, hosting, network traffic, and LLM calls for questions or approved meeting summaries are separate costs. See the Foundry pricing example when using MAI Transcribe 2; other STT models have different rates.

Process Flow recordings and semi-live questions

When a Voice Trigger is bound to a Process Flow recording action, the process instance determines the destination knowledge base; the recorder cannot choose or override it. While recording, the platform saves cumulative transcript snapshots to one draft page at a bounded cadence (no faster than every five seconds). The knowledge view and Shared action conversation remain available alongside the recorder, so authorized process participants can ask semi-live questions against the same persisted draft and the instance's governed knowledge.

Only server-persisted transcript content is visible to Cortex. An unpersisted browser buffer is never injected directly into the shared conversation. If a draft write fails, recording continues locally, the UI displays a warning, and the platform retries.

Calm view retains the full transcript in a scrollable history. It follows incoming text while you are at the bottom and lets you scroll back to earlier contributions.

Live draft checkpoints include settled transcript segments only. Interim text remains visible in the recorder but does not reserve a durable segment sequence while the provider is still revising it.

Stopping the recording flushes settled transcript text, persists the audio, and starts a durable full-recording transcription while the action remains open. This pass works from stored audio references in bounded windows, so long or recovered recordings do not need to fit into one browser or transcription request. The windows are converted to FLAC for transcription, including with MAI; the original recording is preserved. The final pass preserves timed transcript segments and attaches them to the recording’s speaker timeline, including saved identities from a continuous diarizing stream. The final transcription vendor does not need to be the speaker source. Without a session speaker timeline, text remains available with unattributed speakers. When it finishes, you can correct the transcript and speaker assignments before confirming them.

Confirmation saves exactly the revision you reviewed and then derives the meeting's action items, decisions, requirements, risks, and notes from that approved text. The action completes only after those writes succeed. If publication or extraction fails, the action remains open for retry; retries update the same transcript, audio, and derived items instead of creating duplicates.

Click a speaker label to assign a person or role. If one person holds several roles, Assign this speaker groups those roles under their name; select the role they are speaking in. Searching by name also finds all of that person's roles.