Embedded Service
Embedded Service is the Salesforce framework that places service channels onto an external website, mobile app, or Experience Cloud site through a small JavaScript snippet.
Definition
Embedded Service is the Salesforce framework that places service channels onto an external website, mobile app, or Experience Cloud site through a small JavaScript snippet. From a single configuration in Setup, customers can start a conversation, search Knowledge, or submit a case without leaving the page or signing in. The widget renders on the host site and pipes data back into Service Cloud.
The framework is alive, but its original chat channel is not. The first generation, known as Embedded Service Chat or Snap-ins Chat, ran on the old Live Agent engine. Salesforce retired that legacy chat on February 14, 2026. New work now uses Messaging for In-App and Web, with Enhanced Chat for real-time conversations, deployed through the same Embedded Service Deployments setup node.
How Embedded Service evolved and what it covers today
What the snippet actually does on a web page
Embedded Service works by adding a short block of JavaScript to the host site. That snippet loads a bootstrap script from Salesforce, reads the deployment settings you defined in Setup, and draws a floating button and conversation panel into the page. Nothing about your Service Cloud data model is exposed in the markup. The customer sees a styled widget; the heavy lifting happens through Salesforce APIs behind it. You generate the snippet inside an Embedded Service Deployment record, then paste it into your site template or tag manager. Because the code is small and self contained, marketing teams can drop it onto a campaign page without a full development cycle. The same deployment can target one site or many, and you can scope it to specific URLs. For Enhanced Chat and Messaging for Web, the snippet also needs your enhanced domain and a trusted URL entry, so the browser allows the cross origin calls back to your org.
From Snap-ins to Embedded Service to Messaging for In-App and Web
The feature has carried three names over its life. It launched as Snap-ins, a set of components you could snap onto a website or mobile app. Salesforce rebranded the web and app pieces to Embedded Service, and the chat channel became Embedded Service Chat running on the Live Agent infrastructure. That generation handled real-time chat, Knowledge search, case forms, appointment booking, and video. The chat half is now history. Live Agent, Salesforce Chat, Embedded Chat, and Service Chat all reached end of support and were retired on February 14, 2026. Anything still running after that date is provided as-is, with no warranty or service level agreement. The replacement is Messaging for In-App and Web, built on Hyperforce. It keeps the chat features people relied on and adds asynchronous, persistent conversations. The web deployment for that product is sometimes called Embedded Service for Web or Enhanced Web Chat, and it slots into the same deployment framework.
Enhanced Chat versus legacy synchronous chat
Legacy Embedded Service Chat was strictly synchronous. If the customer closed the tab or lost signal, the conversation ended and the context was gone. Enhanced Chat, part of Messaging for In-App and Web, changes that model. A conversation can pause and resume. The customer can move across tabs and devices and pick the thread back up without disconnecting, and the history stays in the window beyond a single visit. Enhanced Chat still supports a real-time experience when an agent is live, so it does not feel slower for the customer. It adds capabilities the old engine lacked: an API to delete conversation data, flow templates through Individual-Object Linking for messaging sessions, a library of structured content components reps can send, and conversation intelligence rules that alert supervisors when flagged keywords appear. Migrating requires Lightning Experience. Orgs still on Salesforce Classic have to move to Lightning first before they can stand up Enhanced Chat.
The Embedded Service Deployment record
Every embedded experience starts with a deployment. In Setup, search for Embedded Service Deployments and create a new one. You pick a conversation type, and that choice is permanent for the deployment once saved, so plan it deliberately. Modern deployments use Enhanced Chat or Messaging for Web rather than the retired Embedded Chat type. A deployment needs a site endpoint. You point it at an Experience Builder site or a Salesforce site, which gives the embedded session a guest user profile to run under. That guest user controls what an unauthenticated visitor is allowed to see and do. From the deployment you set the visual style, the channels, the pre-chat fields, and the routing target. The deployment is also where the installable code snippet lives. Multiple deployments can coexist, so a consumer storefront and a B2B partner portal can each have their own look, language set, and routing rules without interfering with one another.
Routing conversations with Omni-Channel
Embedded Service does not decide who answers a conversation. Routing belongs to Omni-Channel, the same engine that distributes cases, calls, and other work to agents based on skills, capacity, and priority. A messaging conversation lands in the routing layer, Omni-Channel finds an available agent who matches, and the work appears in that agent's Service Console next to everything else they handle. For Messaging for In-App and Web, routing is wired through an Omni-Channel Flow rather than simple queue assignment. The flow gives you branching logic before a human ever sees the conversation. You can inspect pre-chat data, check business hours, send the visitor to a bot first, or pick a queue based on the issue type. That flow is a prerequisite. Without Omni-Channel and a routing flow in place, an Enhanced Chat or Messaging deployment has nowhere to send its conversations, and customers sit waiting with no agent attached.
Authentication, guest access, and pre-chat
An embedded conversation can run anonymously or with the visitor verified. Anonymous mode is the quickest path to launch, because any visitor on the page can open the widget and start talking. The trade-off is thin context. The agent knows only what the customer types or what a pre-chat form collects. Pre-chat forms sit between the click and the agent. They gather a name, email, account number, or issue category, and that data both personalizes the session and feeds routing decisions. Collecting more raises routing accuracy but adds friction, so most production sites settle on a short form. Verified messaging goes further by confirming the visitor's identity and passing trusted customer context, such as account and support history, into the conversation. That depends on identity setup and the guest user permissions tied to the deployment's site endpoint. Getting that guest user profile right matters, because it defines the floor of what an unauthenticated visitor can reach in your org.
Bots, Agentforce, and tier-one deflection
Embedded Service is a natural front door for automation. An Einstein Bot, or an Agentforce Service Agent, can answer the visitor first, resolve common questions, and only hand off to a human when the issue needs one. Tier-one deflection like this cuts agent load and often improves the customer experience, because simple questions get instant answers instead of waiting in a queue. The handoff is where design effort pays back. A bot should capture what it learned, attach that context, and escalate cleanly through Omni-Channel so the agent does not start from zero. Enhanced Chat and Messaging integrate with Agentforce Service Agents for exactly this pattern, blending generative responses with deterministic flows. Measure the deflection rate and the rate at which escalated conversations close successfully. Those two numbers tell you whether the bot is genuinely helping or quietly frustrating people into abandoning the widget before they reach a human.
Create an Embedded Service deployment for Enhanced Chat
Stand up a modern embedded conversation by creating an Embedded Service Deployment that uses Enhanced Chat or Messaging for Web, then installing its generated snippet on your site. This assumes Messaging for In-App and Web is provisioned and Omni-Channel routing exists.
- Prepare the org
Confirm Messaging for In-App and Web is enabled, you are in Lightning Experience, and an Experience Builder or Salesforce site exists to serve as the endpoint. Set up Omni-Channel and an Omni-Channel Flow to route conversations.
- Create the deployment
In Setup, open Embedded Service Deployments and click New Deployment. Choose Enhanced Chat or Messaging for Web as the conversation type. Remember the type is permanent for this deployment once you save.
- Set endpoint and routing
Select the site endpoint so the session runs under a guest user profile. Point the deployment at your routing flow or queue, then configure pre-chat fields, branding, and supported languages.
- Install the snippet
Copy the generated code snippet and your enhanced domain reference, add the host site as a trusted URL, then paste the snippet into your site template or tag manager and publish.
- Test and iterate
Open the page, start a conversation, and confirm it reaches an agent through Omni-Channel. Verify pre-chat data, styling, and any bot handoff before scaling to more pages.
A human-readable label for the deployment that appears in Setup and reporting.
The developer name auto-populated from the label, used in code and metadata references.
Enhanced Chat or Messaging for Web. The selection is locked once the deployment is saved.
An Experience Builder or Salesforce site that supplies the guest user profile for unauthenticated visitors.
- The conversation type cannot be changed after you save the deployment, so picking the retired Embedded Chat type instead of Enhanced Chat means starting over.
- No site endpoint appears in the menu if your org has no Experience Builder or Salesforce site configured. Create one first.
- Enhanced Chat requires Lightning Experience. Orgs still on Salesforce Classic must migrate to Lightning before deploying it.
- Conversations go nowhere until Omni-Channel and a routing flow are in place. Build routing before you publish the snippet.
Prefer this walkthrough as its own page? How to Embedded Service in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Embedded Service.
Hands-on resources to go deeper on Embedded Service.
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. How does Embedded Service surface service capabilities on an external website?
Q2. Through what engine do Embedded Service chats reach a live agent?
Q3. What does an Embedded Service pre-chat form accomplish before connecting a visitor?
Discussion
Loading discussion…