#Embedded Service Deployment4 discutindo

Hi Seema, this is expected. An Embedded Service Deployment always points to a Site endpoint, and Sites (Force.com

or Experience) do not migrate through change sets or the Metadata API, so in QA the deployment references a Site that does not exist, hence site not found or cannot be created. 

Fix, in order: 

1. In QA, create and ACTIVATE the Site first (Setup, Sites, or the Experience site if Dev uses one) so QA has its own site domain. 

2. Re-add your CSP Trusted Sites and CORS allowlist entries for the host page domain, or the widget loads but stays blocked. 

3. Then deploy the Embedded Service Deployment plus its supporting metadata (chat or messaging config, flows, fields) pointing at that QA Site. 

4. Do not reuse the Dev code snippet on the page, it hard-codes Dev org URLs. Copy the fresh snippet Salesforce generates for the QA deployment. 

The Site is org-specific, so it can never come across in the change set itself. You build and activate it in the target org first, then layer the deployment on top. 

If this helps, please mark it as the Best Answer so it helps the next person, thanks 🙂

Hey Megan, 

Adding one thing to Himanshu's answer since it's mostly right but slightly understates option 2: Salesforce actually has a fully supported LWC-based header customization for Messaging (lightningSnapin__MessagingHeader target), you extend the base chat header component and can add whatever fixed text/markup you want inside it. This is documented and stays visible for the whole conversation, unlike the greeting-message approach, which scrolls away. 

So realistically you have two solid, supported paths: 

1. Custom LWC header (extends BaseChatHeader/MessagingHeader), gives you a persistent banner area inside the actual chat window that Salesforce won't overwrite on releases, since it's a supported customization point, not DOM hacking 

2. A banner on your host page around the widget (Himanshu's option 1), simplest if the disclaimer doesn't need to be inside the chat window itself 

Both are supported. The custom header route is probably closer to what you're picturing since it sits inside the widget alongside "Powered by Agentforce," not just around it. 

Reference: