Service Digital Engagement Messaging Site Integrate

Embed Messaging Widget on an Experience Cloud Site

Wires an existing Embedded Messaging (MIAW) deployment onto an Experience Cloud site by retrieving the site's bundle (LWR DigitalExperienceBundle or Aura ExperienceBundle), patching the home page JSON to place the experience_messaging:embeddedMessaging component, staging the bundle into the local project, deploying it, publishing the site, and verifying guest access.

The operation is idempotent: if the component is already present it is updated in place (its id is preserved), so re-running with different ESD coordinates cleanly updates.

Scope

• In scope: Detecting LWR vs Aura bundle type; scaffolding missing LWR template routes required by the site template (e.g. too-many-requests); patching all sfdc_cms__themeLayout/*/content.json files to insert or update the Embedded Messaging component in the footer region (site-wide placement); staging the bundle into force-app; async deploy with polling; resolving the Network.Name and publishing the site; guest-URL smoke test; manual Experience Builder fallback with a deep link.
• Out of scope: Creating the EmbeddedServiceConfig (Embedded Service Deployment) itself — use service-digital-engagement-deployment-configure; creating the MessagingChannel — use service-digital-engagement-channel-configure; creating the Experience Cloud site itself — use experience-lwr-site-generate; generating a standalone JS snippet for a non-Experience website.

Clarifying Questions

Before executing, ask the user if not already clear:

• Site name? The DeveloperName of the Experience Cloud site (the metadata folder name under digitalExperiences/site/<siteName>/ or experiences/<siteName>/).
• Deployment coordinates? The deploymentName (Embedded Service Deployment DeveloperName), the scrtUrl, and the siteEndpoint (Experience site base URL). All three come from the published EmbeddedServiceConfig — obtain from service-digital-engagement-deployment-configure output if not provided.
• Target org alias? For the sf commands.
• URL path prefix? The site's UrlPathPrefix (needed to resolve Network.Name for publish and to hit the guest URL for verification).

Required Inputs

Gather or infer before proceeding:

• Site name — DeveloperName of the site
• Deployment name — DeveloperName of the EmbeddedServiceConfig
• scrtUrl — SCRT2 endpoint URL from the deployment
• siteEndpoint — Base URL of the Experience site
• Target org alias
• URL path prefix — Site's public URL path segment (e.g. esw-site)

Defaults applied to the component's attributes when writing:

• isExpSiteAuthMode: false
• hideChatButtonOnLoad: "Default"
• clientVersion: "WebV1"

Workflow

Steps are sequential. If any automated step fails, proceed to the manual fallback (Phase 6) and do not claim the widget is "live" until either the guest-URL smoke test returns 200 or the user confirms manual publish.

Phase 1 — Detect Bundle Type

1. Retrieve both candidate bundles into <retrieve-dir>. The script only performs a deterministic path check, so the retrieve calls must run first:

   sf project retrieve start --metadata "DigitalExperienceBundle:site/<siteName>" \
     --target-org <org-alias> --target-metadata-dir <retrieve-dir>
   sf project retrieve start --metadata "ExperienceBundle:<siteName>" \
     --target-org <org-alias> --target-metadata-dir <retrieve-dir>

Either call may return "no metadata found" — that is expected; the missing bundle simply means the site is the other type.

1. Run `scripts/detect_bundle_type.sh <retrieve-dir> <siteName>`. It emits exactly one token to stdout:

• LWR → the LWR marker file exists (digitalExperiences/site/<siteName>/sfdc_cms__view/home/content.json). Go to Phase 2.
• AURA → the Aura marker file exists (experiences/<siteName>/views/homeGuestLayout.json). Go to Phase 3.
• UNKNOWN (exit code 1) → neither marker exists. Skip to the manual fallback in Phase 6.

Read references/bundle_detection.md for retrieval command shapes and troubleshooting.

Phase 2 — Patch the LWR Bundle

1. Scaffold any missing LWR template routes (commonly too-many-requests) before patching — missing routes fail the deploy. Route+view scaffolding is owned by experience-lwr-site-generate (see its configure-content-route.md, configure-content-view.md, and handle-component-and-region-ids.md). Delegate to that skill for the actual scaffold; this skill only supplies the messaging-specific context (which route the deploy is complaining about, and confirmation that the scaffolded pair resolves that specific deploy error). See references/lwr_route_scaffolding.md for the delegation pointer.

1. Patch all themeLayout files by running:

   scripts/patch_lwr_bundle.sh \
     <retrieve-dir>/digitalExperiences/site/<siteName> \
     <deploymentName> <scrtUrl> <siteEndpoint>

The script iterates every sfdc_cms__themeLayout/*/content.json file. For each, it locates the footer region at .contentBody.component.children[], walks into the existing community_layout:section wrapper's inner slot region, and either updates the existing experience_messaging:embeddedMessaging component in place (preserving its id) or appends a fresh component node. Targeting the themeLayout footer makes the widget site-wide (floating overlay on every page), equivalent to the Aura themeFooter placement. See references/lwr_patch.md for the JSON shapes and how to verify.

1. Proceed to Phase 4.

Phase 3 — Patch the Aura Bundle

1. Patch the home guest layout by running:

   scripts/patch_aura_bundle.sh \
     <retrieve-dir>/experiences/<siteName>/views/homeGuestLayout.json \
     <deploymentName> <scrtUrl> <siteEndpoint>

The script iterates .regions[], picks the first region whose .components[] is non-empty, recurses through any forceCommunity:section wrappers, and either updates the existing .componentName == "experience_messaging:embeddedMessaging" component in place (preserving id) or appends a fresh forceCommunity:section wrapper. Aura uses componentName / componentAttributes (not definition / attributes) and has no dxpStyle. See references/aura_patch.md for JSON shapes and verification steps.

1. Proceed to Phase 4.

Phase 4 — Stage and Deploy

1. Copy the modified bundle into the project's default package. Use cp -R so unchanged files travel with the modified one:

• LWR: cp -R <retrieve-dir>/digitalExperiences force-app/main/default/
• Aura: cp -R <retrieve-dir>/experiences force-app/main/default/ and also copy the sibling <siteName>.site-meta.xml file — Aura deploys are rejected without it.

1. Async deploy and poll:

    sf project deploy start --source-dir force-app/main/default \
      --target-org <org-alias> --async

Poll every 15 seconds up to 10 minutes:

    sf project deploy report --job-id <job-id> --target-org <org-alias>

Stop when status is Succeeded, Failed, SucceededPartial, or Canceled. On failure, surface the deploy report and do not proceed to publish. See references/deploy_and_publish.md for the full polling loop and common failure modes.

Phase 5 — Publish and Verify

1. Resolve the `Network.Name`. Network.Name frequently differs from the site DeveloperName, so query it by the URL path prefix rather than guessing:

    sf data query --query \
      "SELECT Name FROM Network WHERE UrlPathPrefix='<urlPath>' LIMIT 1" \
      --target-org <org-alias>

1. Publish the community with the resolved name:

    sf community publish --name "<resolved-Name>" --target-org <org-alias>

1. Smoke-test guest access by hitting the public URL: