Mac Dictation Not Working in Salesforce? 9 Fixes That Actually Work

Short answer: Salesforce has no dictation setting of its own, so failures come from macOS Dictation, your browser, or the field type you are dictating into. Test in TextEdit first. If that works, the culprit is usually a Lightning rich text field, console focus loss, or managed browser policy.

You finish a call, open the opportunity record, click into the notes field, press your dictation shortcut, and speak two minutes of context that would take ten minutes to type. Then one of four things goes wrong. Nothing appears. Text appears but the record saves empty. The field loses focus halfway through because the record refreshed. Or everything looks fine until you hit Save and a validation error throws it all away.

Salesforce is unusually good at producing all four, because it is not one text environment. It is a large web application with at least half a dozen different kinds of editable field, running inside a browser that your IT department may be centrally managing, often inside a console with tabs that reload underneath you.

The good news is that the failures sort cleanly into categories, and one thirty-second test tells you which category you are in. Here is that test, followed by nine fixes in the order that resolves the most cases fastest.

Start here: the test that splits the problem in two

Salesforce does not have a dictation feature of its own. Nothing in Setup controls it. So a dictation failure inside Salesforce belongs to one of two independent systems, and they have nothing to do with each other:

• macOS Dictation. Transcribes your speech and types the result into whatever field currently has focus, anywhere on your Mac. Salesforce cannot see it happening and cannot block it.
• The browser and the page. The field type, the focus behaviour, the permission model, and any policy your organisation applies to the browser.

To find out which one is broken:

1. Open TextEdit and create a blank document.
2. Press your dictation shortcut and speak a sentence.

If nothing appears in TextEdit, the problem is macOS-level. Go to fix 1 and stop worrying about Salesforce.

If the sentence appears cleanly in TextEdit, macOS Dictation is healthy and the problem is in the page. Skip to fix 3.

There is a useful refinement. Inside Salesforce, try dictating into the global search box at the top of the page. That is a plain input with none of the rich-text or console complications. If dictation works in global search but fails in a record field, you have narrowed the problem to that specific field type, which is fixes 5 through 8.

Fix 1: Repair macOS Dictation itself

If the TextEdit test failed, work through this in order:

• Open System Settings, go to Keyboard, then Dictation, and confirm the toggle is on.
• Toggle it off, wait a few seconds, then back on. This re-registers the service and clears a surprising number of stuck states.
• Check the Microphone Source setting. If it is pointed at a headset you have since unplugged, dictation is faithfully listening to a device that is not there.
• Check the Shortcut setting. If it is set to the Globe key, go back to the main Keyboard pane and look at the Press 🌐 key to dropdown. On many Macs that is set to change the input source or show the emoji picker instead, so your Globe press never reaches dictation. Set the shortcut to pressing Control twice and test again.
• Restart the Mac. Dictation depends on background services that occasionally need a clean start, particularly after a system update.

If dictation broke immediately after a macOS upgrade, that pattern has a specific set of causes covered in our guide to Mac dictation not working after a macOS update.

Fix 2: Free the microphone, and check the browser's permissions

Sales work runs on calls, and calls hold the microphone. If a dialer, a video meeting client, a call recorder, or a conversation-intelligence tool has claimed the input device, dictation can open and capture nothing but silence.

Quit those applications rather than muting them. Muting inside a call app usually keeps the device claimed. This is the single most common cause among people who dictate call notes, because the tool that was recording the call is often still running when they go to write it up.

Then check permissions. Open System Settings, Privacy & Security, Microphone, and confirm your browser is listed and enabled. Two things worth being precise about:

• macOS Dictation does not need the browser to have microphone permission. Dictation captures audio at the system level and delivers the result as keyboard input. If dictation works in TextEdit, your microphone and system permission are already fine.
• Any third-party dictation tool you run needs its own entry under Microphone, and usually under Accessibility too, so it can insert text into other applications. Quit and reopen the tool after granting the permission. macOS often will not apply a new permission to an already-running process.

Fix 3: Site permission and the per-profile trap

Click the icon at the left edge of the address bar on your Salesforce tab and confirm the microphone is set to Allow. In Chrome you can review the full list at chrome://settings/content/microphone.

Again, this governs features that record audio inside the page, not macOS Dictation. Clear it anyway so you can rule it out, and because some Salesforce-adjacent tools do use in-page audio.

The trap that wastes the most time here: Chrome stores permissions per profile. Sales teams very often run a work profile alongside a personal one. Granting microphone access in one profile does nothing at all for the other, and the settings pages look identical, so it is easy to fix the wrong one twice. Confirm which profile your Salesforce tab is actually open in before you change anything.

Extensions are the other browser-level suspect. Sales stacks accumulate them: engagement tools, dialers, note-takers, enrichment sidebars, screen recorders. Any extension that injects UI into the Salesforce page can interfere with focus. Test in a private window, where extensions are disabled by default. If dictation works there, re-enable your extensions in halves until the culprit shows itself. The general browser causes are covered in more depth in our guide to Mac dictation not working in Chrome.

Fix 4: Managed browser policy that silently overrides what you can see

This one is specific to corporate environments, which describes most Salesforce orgs.

If your Mac is enrolled in device management, your browser may be running under centrally applied policy. Policy can disable audio capture outright, and when it does, the setting in the browser's own preferences may still appear to say Allow. You will change it, it will look correct, and it will keep failing.

In Chrome, open chrome://policy to see every policy currently applied to your browser. Look for anything governing audio capture or media permissions. If a policy is blocking it, no amount of clicking in settings will help. That is a conversation with your IT team, not a fix you can apply yourself.

Worth knowing: even where policy blocks in-page audio capture, macOS Dictation typically still works, because it never asks the browser for the microphone. If your organisation blocks browser audio capture for compliance reasons, system-level dictation is often the sanctioned path. Confirm with your security team rather than assuming.

Fix 5: Rich text fields that look filled but save empty

This is the most Salesforce-specific failure on the list, and the most frustrating, because it looks like success right up until it isn't.

Salesforce uses several different editors depending on where you are. Plain Text and Text Area fields are ordinary inputs. But Rich Text Area fields, the Chatter publisher, Notes, the Lightning email composer, and several case and activity composers use rich text editors instead. Under the hood these are editable regions rather than simple inputs, and they track their own internal state.

The practical symptom: dictated text appears in the field on screen, but the editor never registers that its contents changed. You click Save, and the field writes empty or reverts to what was there before.

How to confirm and work around it:

• After dictating, click into the field and type a single character, then delete it. That keystroke forces the editor to notice its content changed. If the record now saves correctly, you have confirmed the diagnosis.
• Alternatively, dictate into a plain field first, or into TextEdit, then copy and paste into the rich text field. Paste triggers the editor's own handling and is reliably registered.
• Watch the cursor position. Rich text editors sometimes place dictated text at the start of the field rather than at the caret, or split it across an existing paragraph. Read the field back before saving.

If most of your writing goes into rich text fields, the type-a-character trick gets old quickly. That is the point where a tool that inserts at the cursor the same way a keyboard does becomes worth having, which is covered further down.

Fix 6: Console tabs and record refresh stealing focus mid-sentence

If you work in the Sales Console or Service Console, you are in a multi-tab environment where several records are open at once and components refresh independently.

Two things break dictation here:

• Focus theft on refresh. A record page that reloads while you are speaking pulls focus out of the field you were dictating into. The transcription completes, finds no valid destination, and vanishes. This is common when a related list updates or a workflow fires while you are mid-note.
• Ambiguous focus across subtabs. With multiple subtabs open, clicking a field in one does not always leave focus where you expect, particularly right after switching tabs.

The practical habit: after clicking into a field, look for the caret and give the page a second to settle before you start speaking. If a record is actively updating, wait for it. For long notes, dictate somewhere stable and paste in, rather than fighting a page that is refreshing under you.

This applies equally to any record page with heavy automation behind it, not just the console.

Fix 7: Field length caps and validation rules

Sometimes dictation worked perfectly and Salesforce threw the result away for reasons that have nothing to do with voice.

• Length caps. A standard Text field caps at 255 characters. A Long Text Area holds far more. Two minutes of speech is comfortably several thousand characters, so dictating a call summary into a field that was defined as a short Text field will truncate or reject it. If your text keeps getting cut off at the same point, this is why, and the fix is an admin changing the field type.
• Validation rules. Your org may enforce required formats, forbidden characters, or minimum lengths. A dictated passage that includes punctuation the rule does not expect will fail validation on save. Read the error message rather than assuming dictation dropped the text.
• Field-level security. If you lack edit access to a field, it renders read-only, and dictated text has nowhere to go. Check whether you can type into it manually first.

The general rule: before blaming dictation, try typing three words into the same field by hand and saving. If typing also fails, the problem is the field, not your voice.

Fix 8: Visualforce pages and embedded frames

Plenty of Salesforce orgs still run Visualforce pages, embedded canvas apps, and third-party components inside Lightning. These render inside frames that are separate documents from the page around them.

Focus behaves differently across that boundary. Click directly into the field inside the frame and confirm the caret is visible before you speak. Clicking the surrounding Lightning page and assuming focus carried through is a common mistake, and dictated text lands nowhere.

Embedded components that load asynchronously have the same re-render problem as console tabs. Let the component finish loading. If a particular embedded field is consistently hostile to dictated text, dictate elsewhere and paste.

Fix 9: The language mismatch that turns clean audio into nonsense

This one gets misdiagnosed constantly because dictation appears to be working perfectly. Words arrive promptly, punctuated, confident. They are simply the wrong words.

If the configured dictation language does not match what you are speaking, the system maps your audio onto the vocabulary it was told to expect, and you get fluent nonsense. Open System Settings, Keyboard, Dictation, and check the Languages list. If several are enabled, confirm the active one matches what you speak, and remove any you do not need.

A milder version of the same problem is the reason most sales teams give up on dictation: your vocabulary is not general English. Account names, product SKUs, competitor names, stage names, and the acronym soup of pipeline work all get transcribed as whatever ordinary word sounds closest. MQL, SQL, ARR, ACV, POC, and half your product catalogue come out wrong, every single time, and correcting them by hand erases the time you saved.

The workflow that avoids most of this

Every fix above works around the same structural issue. macOS Dictation is a mode you enter, focus is fragile while you are in it, and it knows nothing about your company's vocabulary.

Voice Keyboard Pro is shaped differently. It sits in the menu bar. You hold a hotkey, speak, and release, and the text appears at your cursor in whatever app is frontmost. There is no session to start and end, no window to dismiss, and no ambiguity about when capture is happening, because you are holding the key the whole time you are speaking. Because the insert happens at the cursor the way typed input does, it behaves consistently across plain fields, rich text editors, and embedded frames alike.

For CRM work specifically, two features do the heavy lifting.

Smart Vocabulary is a personal dictionary with replacement rules. Teach it your account names, product names, stage names, and internal acronyms once, and they come out spelled and cased correctly every time after that. This is the difference between dictation being a novelty and dictation being how you actually update records, because the correction tax is what kills it otherwise.

Meeting Mode captures a call with speaker detection and produces AI notes, and calendar meeting detection means it can offer to start when the meeting does. The pattern that works well is to let Meeting Mode capture the discovery call, then dictate the short structured summary into the opportunity record afterwards, rather than trying to type notes while you are supposed to be listening.

On privacy, which matters when the subject is customer data: our server stores only operational pings. No audio and no transcript content is retained. What you dictate into a customer record stays between your Mac and that record.

There is a free tier with daily limits, and Pro is $4.99 a month or $34.99 a year.

What voice is actually good for in Salesforce

Being straight about this is more useful than overselling it.

Voice is good for: call summaries and next steps, activity logging, opportunity notes and deal context, case comments and resolution write-ups, Chatter updates, meeting recaps, and the long narrative fields that everyone leaves blank because typing them is tedious. These are exactly the fields that make a CRM useful and exactly the ones that go unfilled.

Voice is bad for: picklists, currency amounts, close dates, probability percentages, record IDs, and anything you select rather than write. Do not fight the interface for those. Click them.

The gain is a plain speed difference. Most adults type around 40 words per minute; professional typists reach 80 to 100. Everyone speaks comfortably at 130 to 150. On a three-paragraph call summary, that is the gap between a task you postpone until Friday and one you finish in the parking lot before your next meeting. Pipeline hygiene problems are usually not discipline problems. They are friction problems.

The notes field is empty because typing it took eight minutes. It takes ninety seconds to say.

Quick reference

• Nothing works anywhere, including TextEdit: system-level. Toggle dictation off and on, check microphone source, restart.
• No microphone indicator at all: the shortcut is not firing. Check the Globe key setting.
• Silence captured after a call: the dialer or recorder still holds the microphone. Quit it, do not just mute.
• Works in global search, fails in a record field: field-type problem. Fixes 5 to 8.
• Text appears but saves empty: rich text editor did not register the change. Type and delete one character, or paste instead.
• Text vanishes mid-sentence: the record refreshed and stole focus. Let the page settle first.
• Always truncated at the same length: the field is a short Text field, not a Long Text Area.
• Setting says Allow but still blocked: check chrome://policy for managed policy.
• Fluent output, wrong words: language mismatch in Dictation settings.
• Right words, wrong account and product names: you need a vocabulary layer.

If you want the workflow rather than the failure modes, our guide to dictating in Salesforce covers day-to-day use, dictation for CRM updates looks at the habit side of keeping records current, and voice to text for salespeople covers the wider sales workflow including prospecting and follow-up.

Most Salesforce dictation problems come down to three things: a microphone still held by a call tool, a rich text field that never noticed the text arrive, or a page that refreshed while you were talking. Check those three before you touch anything in Setup.