Messaging for Web
Messaging for Web is the Service Cloud channel that lets a customer message a support agent through a chat widget embedded on a website.
Definition
Messaging for Web is the Service Cloud channel that lets a customer message a support agent through a chat widget embedded on a website. The visitor clicks a chat button, a window opens, and each message travels to Salesforce as a Messaging Session that an agent works inside the Service Console. Salesforce now markets this channel, together with its mobile sibling, under the name Enhanced Chat.
A defining trait is asynchronous conversation. The customer can close the browser tab, return hours later, and find the thread waiting with the agent's reply. That behavior, plus native bot handoff and Omni-Channel routing, separates Messaging for Web from the older Legacy Chat (Live Agent) product, which Salesforce retired on February 14, 2026. New websites should deploy Messaging for Web, not the retired chat.
How a web chat becomes a Messaging Session
The embedded code snippet
Delivery starts with an Embedded Service Deployment. An admin configures the deployment in Setup, then copies a generated JavaScript snippet onto every page that should host the widget. The snippet loads the Salesforce-hosted bootstrap library, draws the chat button, and runs the whole conversation client-side. For an Experience Cloud site, the same code goes in the head markup of the site rather than a raw HTML page. The bootstrap object is named embeddedservice_bootstrap, and it exposes the settings and methods that control the widget. Calls to those methods must wait until the client fires the onEmbeddedMessagingReady event, because the library is not ready before that. The snippet is small, often under a dozen lines, yet it carries the deployment name, the org's base URL, the site URL, and a few initialization parameters. Because the heavy lifting lives in the hosted library, a Salesforce upgrade can change widget behavior without the website team touching their page. That tradeoff keeps the integration light but means the deployment configuration in Salesforce, not the page, is where most behavior is tuned.
Asynchronous conversations
Messaging for Web treats a conversation as durable, not as a live session that dies when the page unloads. A visitor can start a chat, navigate away, close the tab, and come back later to the same thread with any agent or bot replies intact. Salesforce keeps the conversation tied to the person through a persistent identity, stored client-side and matched to a MessagingEndUser record on the server. For an anonymous visitor that identity is scoped to the browser, so the thread survives page loads and short absences. For a signed-in visitor the deployment can pass an identity token, which ties the conversation to a known Contact and lets the same person resume from another device. This async model is the headline reason Salesforce steered customers off Legacy Chat, where a dropped connection usually ended the chat. It also changes agent expectations: a Messaging Session can stay open across a long gap, so capacity and routing rules account for conversations that are active but momentarily idle rather than abandoned.
Bot triage and agent handoff
Most Messaging for Web deployments open the conversation with a bot rather than a human. The bot greets the visitor, reads intent, answers routine questions, and escalates to an agent only when the case needs a person. Salesforce now positions Agentforce and the Einstein Bot framework as the conversational layer here, and the same bot can serve web, in-app, SMS, and WhatsApp because they share one messaging foundation. That reuse matters in practice: a team builds one bot, tests it once, and points multiple channels at it instead of maintaining a separate flow per surface. Handoff is not a hard cutover. The bot can collect details, set context variables, and pass them to the agent so the human starts informed rather than asking the visitor to repeat everything. When no agent is available the bot can still capture the request, and because the conversation is asynchronous the customer gets a reply later in the same thread. Deflection through the bot is often the main return-on-investment argument for the channel, since it keeps routine traffic away from agents.
Omni-Channel routing
Once a conversation needs a human, Omni-Channel decides which agent gets it. Messaging for Web routes the same way that in-app, SMS, and WhatsApp messaging do, so a single routing model covers every text channel. Salesforce recommends routing with Omni-Channel Flows, where a flow evaluates the incoming Messaging Session and assigns it to a queue or directly to an agent based on skills, capacity, and presence. An agent can hold a web chat, an SMS thread, and a WhatsApp inquiry at the same time inside one Service Console, with each conversation counting against their configured capacity. Because the channel is asynchronous, routing also has to handle conversations that reopen after hours, reassigning them to whoever is available rather than waiting for the original agent. Presence, queues, and capacity models are configured once in Omni-Channel and then apply across channels. This is a real difference from Legacy Chat, which used its own chat-specific routing rather than the unified Omni-Channel engine that the rest of Service Cloud already relied on.
The Messaging Session data model
Every web conversation lands in a small set of objects that admins and developers query directly. The MessagingSession record represents one conversation on a Messaging channel and is the object reports and automation usually target. MessagingEndUser represents the address on the other end, meaning the visitor's identity on that specific channel, and a person can hold one end-user record per channel they use. The Messaging channel itself is the configured entry point that the embedded deployment points at. Individual messages and events sit in ConversationEntry records, which capture the back-and-forth between the end user and the agent or bot. Salesforce guides builders to work at the MessagingSession and MessagingEndUser level rather than the lower-level conversation and participant objects. This shared model is why a web chat, an SMS, and a WhatsApp thread all report through the same structure. It also feeds analytics: MessagingSessionMetrics and Data Cloud mapping pull from these records, so a team can measure web-chat volume, handle time, and bot deflection using objects that already exist rather than building custom logging.
Identity, security, and branding
The deployment controls who the visitor appears to be and how the widget looks. For authenticated experiences the snippet can pass a signed identity token so Salesforce resolves the visitor to a Contact and surfaces account history the moment the conversation routes. Anonymous visitors get a session-scoped identity that persists across page loads but does not link to a known record. Security settings on the deployment govern allowed origins and token handling, which matters because the widget runs in the customer's own pages. Branding is configured in Salesforce rather than in code: colors, logo, button placement, the opening greeting, and the agent display name are all set on the deployment, so a brand refresh does not require a website release. Prechat fields can collect a name, email, or case reason before routing, and hidden prechat fields can pass page context the visitor never sees. Keeping identity, security, and branding in the deployment is deliberate, since it lets a Salesforce admin own the customer experience while the web team owns only the thin snippet on the page.
Migrating off Legacy Chat
Legacy Chat, once called Live Agent, was the previous web-chat product, and Salesforce retired it on February 14, 2026. Teams still running it had to move to Enhanced Chat, and the move is a project, not a flip of a switch. Salesforce ships a migration tool that helps convert configuration, but the snippet on the website, the Service Console setup, the routing, and any bot definitions all change. Enhanced Chat requires Lightning Experience, so orgs still on Classic for service had to make that shift as part of the work. The biggest behavioral change agents notice is the asynchronous model, because conversations no longer end when a customer disconnects. Planning usually covers a pilot on a low-traffic page, a review of custom labels and branding, validation of bot handoff, and a cutover window where the old snippet is swapped for the new one. Treating it as a multi-week effort, with the migration tool plus manual reconfiguration, is the realistic expectation rather than a same-day replacement.
Set up a Messaging for Web deployment
Standing up Messaging for Web is an admin task in Setup. You turn on the platform feature, route with Omni-Channel, create a Messaging channel, then publish an Embedded Service Deployment whose snippet goes on the website.
- Turn on Messaging and Omni-Channel
In Setup, enable Messaging settings and confirm Omni-Channel is on. Omni-Channel is required because it routes every Messaging Session to an agent. Assign the messaging permission set to the service users who will handle chats.
- Create the Messaging channel
Create a Messaging channel of the Messaging for Web type. The channel is the entry point that conversations flow through, and it links to the routing and the end-user records the platform creates.
- Configure routing with an Omni-Channel Flow
Build or assign an Omni-Channel Flow that evaluates the incoming session and sends it to a queue or agent by skill, presence, and capacity. Optionally start the conversation with an Agentforce or Einstein Bot for triage.
- Publish the Embedded Service Deployment and add the snippet
Create an Embedded Service Deployment, set branding and prechat, then open Code Snippet in Setup. Copy the generated JavaScript onto the website pages, or into the head markup of an Experience Cloud site.
Colors, logo, button placement, opening greeting, and agent display name, all set on the deployment so the web team never edits the page for a refresh.
Visible fields that collect a name, email, or case reason before routing, plus hidden prechat fields that pass page context the visitor does not see.
A signed token the snippet passes for logged-in visitors so Salesforce resolves them to a Contact and shows account history to the agent.
An optional Agentforce or Einstein Bot that greets the visitor, deflects routine questions, and escalates to a human with context attached.
- Enhanced Chat requires Lightning Experience; orgs still on Classic for service must move before deploying.
- API methods only run after the onEmbeddedMessagingReady event fires; calling them earlier silently does nothing.
- Legacy Chat (Live Agent) was retired on February 14, 2026, so do not build new deployments on it.
- Most behavior lives in the deployment, not the page, so a Salesforce upgrade can change widget behavior without a website change.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Messaging for Web.
- Messaging Object ModelSalesforce
- Replace Legacy Chat with Enhanced ChatSalesforce
Hands-on resources to go deeper on Messaging for Web.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is Messaging for Web?
Q2. How does it differ from traditional web chat?
Q3. What does it replace?
Discussion
Loading discussion…