Voice Input
What It Does
A microphone button next to the message input starts voice capture right in place. When the user speaks, the browser converts the speech into text and it appears in the message field in real time. The user reviews, edits if needed, and sends — the agent processes it like any typed message.
Voice input is a typing alternative, not a separate channel. Once the spoken text becomes a message, the rest of the conversation flows through the standard agent pipeline.
How It Works
-
Click microphone
Recording starts in place, with a listening indicator in the message bar. The browser may prompt for microphone permission on first use.
-
Browser transcribes
Recognised words appear immediately as interim text. Once a sentence is finalised, it’s appended to the running transcript.
-
The user pauses
After about four seconds of silence with text already captured, recording finishes automatically and the transcript stays in the message input. Users who keep speaking continue uninterrupted.
-
Transcript becomes message
The captured text lands in the chat input. The user can edit it before sending or send it as-is.
-
Agent processes
From here, the conversation is identical to any typed conversation — same agent, same tools, same context.
Browser Support
Voice input depends on the browser’s Web Speech API. Support and quality vary:
| Browser | Support |
|---|---|
| Google Chrome (desktop & Android) | Full |
| Microsoft Edge | Full |
| Safari (macOS & iOS) | Full |
| Brave, Opera, Vivaldi (Chromium-based) | Full |
| Firefox | Not supported by default |
On a browser that doesn’t support voice input, the in-Salesforce assistant shows a brief “not available” hint and the user falls back to typing. On the public Community and Website widgets, the microphone button is hidden automatically where it isn’t supported. The rest of the chat still works normally.
Language Detection
Voice input uses the browser’s configured language for speech recognition (the navigator language, set in the browser’s preferences). For users whose Salesforce locale and browser locale match, this just works. When they differ, recognition follows the browser locale, not the Salesforce one.
The transcript is sent to the agent verbatim. The agent’s response language is governed by REDA AI’s language directive, which is based on the user’s Salesforce language — not the browser’s. So a French-locale browser dictating into an English Salesforce user’s session will produce French transcript and English agent reply unless the agent’s prompts handle the mismatch.
Silence Auto-Stop
After about four seconds of silence with text already captured, recording finishes automatically and the transcript is left in the input field. This avoids forcing users to manually click stop after each utterance.
If the user is still speaking when the silence timer would fire, recognition resets and continues; the timer only triggers on actual silence.
Permissions and Privacy
- Microphone permission is browser-managed. The first time a user starts voice input on a site, the browser prompts for microphone access. Denying it disables voice input until the user re-grants permission in browser settings.
- Audio stays on the device. The Web Speech API performs recognition either in-browser or via the browser vendor’s service. REDA AI never receives the raw audio — only the final text the user chooses to send.
- The transcript is the same as any typed message. It’s stored on the Conversation record once sent, subject to the same archival and audit handling as typed messages.
Where It’s Available
Voice input is available in the in-Salesforce assistant (record pages, the home page, and the Lightning utility bar), the Community portal widget, and the Website widget.
In the in-Salesforce assistant it is always on. On the public widgets it is on by default and an admin can switch it off: uncheck Enable Voice Input on the Community component (in Experience Builder), or add data-enable-voice="false" to the Website widget embed. On every widget, the microphone only appears in browsers that support voice input.
Failure Modes
| Symptom | Cause |
|---|---|
| “Voice input is not available in this browser” | The browser doesn’t expose the Web Speech API. Firefox is the most common case. |
| Microphone selected but recording never starts | Microphone permission was denied. Tell the user to re-enable it in browser settings, then refresh the page. |
| Recording starts but words are missed or wrong | Background noise, accent, or low-quality microphone. Voice recognition quality is the browser’s responsibility — users get the same recognition quality they’d get in any other web app. |
| Transcript is in the wrong language | The browser’s language is set differently from what the user is speaking. Adjust the browser language preference; voice input uses that value at startup. |
| Recording stops too quickly mid-sentence | The user paused for several seconds while still wanting to speak. Continue speaking before the silence timer elapses, or click the microphone again to restart. |
Best Practices
Set user expectations on first use. First-time users may not realise the silence auto-stop fires after a few seconds; an in-app tip or onboarding note avoids confusion.
Keep the input field visible after dictation. The transcript lands in the input but isn’t sent automatically. Users should review and edit before pressing send — voice recognition is rarely perfect on the first pass.
Document browser requirements internally. If your organisation standardises on a browser without Web Speech API support, voice input won’t work for those users. Either change the browser standard, or rely on typed input for that population.
Don’t treat voice as a separate channel. The same agent handles both. Use the same prompts, tools and context fields; voice is just a typing alternative.
Frequently Asked Questions
No. Speech recognition happens in the browser; only the final transcript text reaches REDA AI. Audio never leaves the user’s device through this feature.
On the in-Salesforce assistant, voice input is always on — if users shouldn’t use it, control microphone access at the browser or device-management level. On the public widgets you can turn it off directly: uncheck Enable Voice Input on the Community component, or add data-enable-voice="false" to the Website widget embed.
Firefox doesn’t expose the Web Speech API by default. REDA AI detects this — the in-Salesforce assistant shows an unavailable hint, and the public widgets simply hide the microphone; users in Firefox should type instead.
On Salesforce Mobile and most mobile browsers (Chrome on Android, Safari on iOS), yes — subject to the browser’s microphone permission prompt. The user experience is identical to desktop.
Each session uses one language — the browser’s configured language at the time recording starts. Switching languages requires changing the browser language preference and starting a new recording.
The agent’s response language is driven by the user’s Salesforce language, not the browser. If the two differ — e.g. browser in French, Salesforce in English — the agent will reply in English regardless of how the question was dictated. Align the two preferences for a single-language experience.
Yes. Voice input is available on the in-Salesforce assistant, the Community portal widget, and the Website widget. On the public widgets it is on by default (where the browser supports it) and can be switched off by an admin — Enable Voice Input on the Community component, or the data-enable-voice attribute on the Website widget embed.
The transcript lands in the chat input field, not directly into the conversation. Edit the text manually before sending. Voice recognition is the browser’s job — quality depends on background noise, accent, microphone hardware and browser version.
Next Steps
Read Internal Channel for where the chat widget runs, or Multi-Language Agents for how the agent decides what language to respond in.