Embedded Service Deployments
An Embedded Service Deployment is a single configured instance of Salesforce Embedded Service, managed from the Embedded Service Deployments page in Setup.
Definition
An Embedded Service Deployment is a single configured instance of Salesforce Embedded Service, managed from the Embedded Service Deployments page in Setup. Each deployment defines one chat or messaging widget for one external website or Experience Cloud site: which channel is enabled, which site endpoint it points to, how customer conversations are routed, what the widget looks like, and what visitors see before and after they start a conversation. One Salesforce org can hold many deployments, each targeting a different site, brand, region, or audience.
A deployment is the unit you create, edit, clone, and embed. From the Setup page you build it, generate its JavaScript code snippet, and paste that snippet into your web page or Experience Builder site. Important context: legacy Chat (the older snap-ins chat) was retired on February 14, 2026. New deployments use enhanced Chat, which Salesforce also calls Messaging for In-App and Web. The Embedded Service Deployments page remains the home for setting these up.
How an Embedded Service Deployment fits together
One deployment, one widget, one site endpoint
The defining idea is that a deployment maps to a single embeddable experience. When you create one, you name it, pick the conversation type (such as Embedded Messaging or Embedded Chat), and choose a Site Endpoint. The site endpoint is an Experience Builder site or a Salesforce site that hosts the static assets the widget loads. From that point, the deployment owns the full configuration for that one widget. Two deployments embedded on two different domains can present completely different experiences while sharing the same Salesforce org and the same agents behind the scenes. This one-to-one mapping is why companies with several brands or regions usually run several deployments. You build a deployment for the consumer storefront, a separate one for the partner portal, and another for the support help center. Each gets its own snippet. Each can be turned on or off independently. The deployment list in Setup becomes the inventory of every place your org talks to customers through embedded chat, which makes it the first screen an admin checks when a widget misbehaves on one site but works fine on another.
Enhanced Chat replaced legacy Chat
There are two generations of embedded chat, and knowing which one you are on matters. Legacy Chat, the original snap-ins chat that rode on Live Agent, was retired on February 14, 2026. Salesforce moved everyone toward enhanced Chat, branded as Messaging for In-App and Web (often shortened to MIAW). Enhanced Chat keeps the synchronous, here-and-now feel of old chat but adds asynchronous messaging, so a conversation can pause and resume across sessions and devices without losing context. If you still see deployments configured for the old Chat channel, they no longer serve live traffic, and the migration path is to rebuild them as Messaging for Web deployments. The Embedded Service Deployments Setup page hosts both the historical legacy records and the new enhanced ones, so do not assume a deployment is active just because it appears in the list. Check the conversation type. Enhanced deployments route through Omni-Channel flows and support richer features, including persistent conversation history, file attachments, and structured pre-chat that maps directly into a flow.
Channel, routing, and pre-chat configuration
Inside a deployment you wire up how conversations behave. For a Messaging for Web deployment, you connect a messaging channel and decide how inbound conversations reach a human. Routing typically runs through an Omni-Channel flow, which can read pre-chat data, set priority, and assign the conversation to the right queue or skill before an agent ever sees it. Pre-chat is the short form a visitor fills in before the conversation opens. You choose which fields to collect (name, email, reason for contact) and map those values into the routing flow, so the agent opens the chat already knowing who they are talking to. You can also configure business hours and an away experience, so visitors who arrive after hours get a clear message instead of silence. Auto-responses and a welcome greeting set the tone the moment the widget opens. Because routing is decoupled from the widget, you can change how conversations are distributed (different queue, different flow logic) without touching the embedded snippet on the website. That separation keeps front-end and back-end changes independent, which is a real advantage during busy seasons.
Branding and the visitor-facing experience
Each deployment carries its own look. You set the colors, the header text, the logo, the widget position on the page, and the labels visitors read. The branding flows through the whole conversation, from the closed chat button to the open conversation window. This per-deployment styling is what lets one org match several brands at once. A parent company site uses corporate colors and logo, while a subsidiary site running off the same org uses the subsidiary identity. Enhanced Chat exposes branding both through Setup and through code, so a developer can override appearance in the snippet when the standard options are not enough. You can localize the visitor-facing text with custom labels, which matters when the same widget design serves multiple languages. The goal is that the chat feels native to the host site rather than bolted on. Worth remembering: appearance set in the code snippet can override what you picked in Setup, so when a widget looks wrong, check both layers. After any branding or configuration change, you must republish the deployment, otherwise the live snippet keeps serving the old settings to real visitors.
The code snippet and how the widget loads
Configuration only reaches the website through the deployment code snippet. On the Embedded Service Deployments page you open the deployment and use Get Code (the Code Snippet action) to copy a short block of JavaScript. You paste that block into your web page, or into the head markup of an Experience Builder site, and the script loads the widget using the deployment configuration you saved. The snippet points back to your site endpoint, which serves the widget assets. For developers, enhanced Chat exposes JavaScript APIs to start, prefill, and control the conversation programmatically. A key rule: call those APIs only after the client fires the onEmbeddedMessagingReady event, because calls made before the widget finishes initializing simply do not run. This event-gated pattern prevents race conditions when your page scripts and the chat bootstrap load at the same time. Teams that run multiple deployments often standardize a small wrapper around the snippet so each site loads the right deployment based on URL or environment. Getting the snippet placement and load order right is usually the difference between a widget that appears instantly and one that flickers or fails silently.
Metadata, cloning, and the deployment lifecycle
Embedded Service deployments are metadata, so they move through the same release tooling as the rest of your org. You can migrate them with change sets, the Metadata API, or Salesforce DX, and store the definitions in Git for version control. That is how enterprise teams keep dozens of deployments consistent across sandboxes and production instead of clicking each one together by hand. Cloning is the everyday shortcut for variants. You build one canonical deployment, get it exactly right, then clone it and adjust the copy for a different region, language, or brand. The clone is independent, so later edits to the original do not flow into it automatically. Setting up an Embedded Chat or Messaging deployment requires the Customize Application and Modify Metadata permissions, which keeps this in the hands of admins and developers rather than every user. A healthy lifecycle looks like this: build in a sandbox, validate on a staging URL, deploy the metadata to production, then republish so the live snippet picks up the final configuration. Treating deployments as code from day one saves the painful audit later when nobody remembers what each one does.
Create a Messaging for Web deployment
Set up a new Messaging for Web (enhanced Chat) deployment so a chat widget can appear on your website. This assumes Omni-Channel and a messaging channel are already enabled.
- Open the Embedded Service Deployments page
From Setup, type Embedded Service in Quick Find and select Embedded Service. Click New Deployment to start.
- Pick the conversation type and name it
Choose the enhanced messaging option, give the deployment a clear name, and confirm the auto-generated API name. Select the Site Endpoint (an Experience Builder or Salesforce site) that hosts the widget assets.
- Wire up routing and pre-chat
Connect the messaging channel to an Omni-Channel flow that routes conversations to the correct queue or skill. Configure pre-chat fields and map them into the flow so agents see context on arrival.
- Brand the widget and set business hours
Set colors, logo, header text, labels, and widget position. Configure business hours and an away message so off-hours visitors get a clear response.
- Get the code snippet and publish
Use Get Code to copy the JavaScript snippet, paste it into your web page or Experience Builder head markup, then publish or republish the deployment so the live widget uses your settings.
Choose enhanced Messaging for In-App and Web; legacy Chat was retired on February 14, 2026 and should not be used for new builds.
The Experience Builder or Salesforce site that serves the widget assets the snippet loads. Required for the deployment to function.
The routing logic that reads pre-chat data and assigns each conversation to a queue, skill, or agent.
The information collected before the conversation opens, mapped into the routing flow for agent context.
Colors, logo, position, and localized text that make the widget match the host site. Snippet-level overrides can supersede these.
- You need the Customize Application and Modify Metadata permissions to create or edit a deployment.
- Republish the deployment after every change; the live snippet keeps serving old settings until you do.
- Call JavaScript APIs only after the onEmbeddedMessagingReady event fires, or the calls will not execute.
- Settings in the code snippet can override what you chose in Setup, so check both layers when the widget looks wrong.
Trust & references
Cross-checked against the following references.
- Create an Embedded Service DeploymentSalesforce
- Configure a Messaging for Web DeploymentSalesforce
Straight from the source - Salesforce's reference material on Embedded Service Deployments.
- Create an Embedded Service DeploymentSalesforce
- Enhanced Web Chat APIs OverviewSalesforce
Hands-on resources to go deeper on Embedded Service Deployments.
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 customer experience metric would Embedded Service Deployments help improve?
Q2. How does Embedded Service Deployments help support agents be more productive?
Q3. What business function does Embedded Service Deployments primarily support?
Discussion
Loading discussion…