Harriet in Salesforce

Put Harriet on a Salesforce record page for your own staff, signed in as the Salesforce user who is looking at it and aware of the record in front of them. This is different from the public website widget: it is for people who already have a Harriet account, and they get their own permissions, skills and knowledge.

Signed-in embeds vs. the public widget

A widget surface has a setting, Who is this widget for?, with two choices.

	Public visitors	Signed-in Harriet users
Who is chatting	Nobody is signed in	A named Harriet user
What Harriet can see	Public knowledge for that surface	Everything that person can see in Harriet
Conversation history	Held in the visitor's browser	In that person's own Harriet chat list
Where it belongs	Your public website	An internal app you control, such as Salesforce

Signed-in mode works in any app that can frame a page and sign a short string on the server. Salesforce is the worked example because we ship a ready-made component for it.

What you need

Web chat on your Harriet plan.
An active Harriet account for each person who should chat, with the same email address as their Salesforce user. Anyone else sees a clear error instead of an anonymous chat.
A Salesforce admin who can deploy metadata and edit Lightning pages.

Set up the widget in Harriet

Go to Channels & embed → Surfaces and add a widget, or open an existing one.
Set Who is this widget for? to Signed-in Harriet users (internal).
Optionally turn on Share page context with the AI during conversations, so Harriet can use the record name and page address the component sends.
Leave Keep conversations on the current page on so a chat started on one record comes back when you return to it. Uncheck it if one conversation should follow the user between records. The menu still lets you open chats from other pages under Other conversations.
On Browser origins, add your Salesforce hosts, comma-separated:
```
*.lightning.force.com, *.my.salesforce.com
```
Sandboxes sit under lightning.force.com, so the wildcard covers them. This list is also what allows your org to frame the chat page, so no other site can.
On Credentials, generate or reveal the embed signing secret. Note it along with the widget UUID and your customer id from the embed snippet.

⚠️

In signed-in mode the embed signing secret works like a single sign-on key: whoever can sign with it can open a session as any user in your account. Only enable this for apps you control, keep the secret on the server, and treat it like a password.

Install the component in Salesforce

The reference package lives in the salesforce_lwc folder of the Harriet repository, and its README has the deploy commands. In short, your admin:

Deploys the package, which adds an Apex controller, the Harriet Chat Lightning component, a protected custom metadata type for the settings, and a trusted URL for the Harriet host that allows framing and microphone access.
Creates a Harriet Chat Setting record named Default holding the Harriet host, customer id, widget id and signing secret.
Grants the relevant profiles access to the Apex class.
Drops Harriet Chat onto a record, app or home page in the Lightning App Builder.

Apex signs a short assertion naming the current user; the secret never reaches the browser. The assertion is good for five minutes, and Harriet trades it for a session that renews itself, so a record page left open all day keeps working without anyone reloading.

Voice dictation

The chat has a microphone button (Dictate message) next to the attachment button. People select it, speak, and select it again to stop, and the text lands in the message box for them to check before sending. If you deployed the component before this button was added, deploy it again to get it.

Salesforce also controls microphone access. In Setup → Session Settings → Browser Feature Permissions, if your org includes the Permissions-Policy header, set Microphone to Trusted URLs Only (the Harriet trusted URL already allows it) or Always. Where the microphone is blocked, the button does not appear and the chat works as before.

What Harriet knows about the page

When page context is on, the component tells Harriet the object type, the record name and the page address, so "what's the status here?" makes sense without the user pasting anything. Context is a hint for understanding the question. It never grants access to data: every action still runs the normal permission checks for the signed-in user. With Keep conversations on the current page on, Harriet also restores the latest chat for that record when you come back, without moving a chat you opened from elsewhere.

Which widget settings apply

A signed-in embed runs as the person looking at it, so by default Harriet uses their own permissions, skills and knowledge and the widget adds nothing on top. Three settings, one each on the Data and skills and Escalations tabs, let you pin that per widget instead.

Setting	Default	If you pin it to the widget
Knowledge for signed-in users	Everything the person can normally see in Harriet	Narrowed to the data groups and knowledge scope tags you pick. It only ever narrows — nobody sees a document they could not already open in their normal Harriet chat.
Skills for signed-in users	The skills the person normally has	Their own skills plus the ones you select, or only the ones you select. Either way, a skill they are not personally permitted to use (for example one that needs an owner role or access to personal data) stays unavailable.
Escalations for signed-in users	Every ticket inbox in your organisation, exactly as in their normal Harriet chat	Every ticket raised through this widget goes to the groups you pick instead.

Two settings never apply to a signed-in embed, so Harriet switches them off for you: the Transcript sync tab, because these conversations live in the person's own Harriet chat history rather than your CRM, and the New case button on the Customization tab, because a signed-in user raises tickets through normal escalation instead. Role / instructions, also on the Customization tab, does apply. Write who the assistant is in this chat, the same as on a public widget.

Ending access

Access follows the person's Harriet account. Deactivating a user, or switching the widget back to Public visitors, ends their open chats within about fifteen minutes. Regenerating the embed secret on the Credentials page ends every signed-in session immediately, and your Salesforce settings record needs the new secret before chats resume.

If something does not work

Symptom	Usual cause
Blank panel where the chat should be	Your Salesforce host is missing from Browser origins, or the CSP Trusted Site is missing or inactive.
"No Harriet user for that email"	That Salesforce user has no active Harriet account with a matching email address.
"This widget is not configured for signed-in users"	The surface is still set to Public visitors.
Signature errors	The settings record has the wrong secret, or the server clock is far out.
Chat stops after a while	Expected only if the person was deactivated or the secret was rotated; otherwise the session renews itself.
No microphone button, or "Microphone access is blocked here."	The component was deployed before dictation was added, Session Settings block the microphone, or the person turned microphone access off in their browser.

For the public website widget, see Website widget. For signing and the origin allowlist in detail, see Embed security.