Experience UI Bundle Site Generate

Digital Experience Site for React UI Bundles

Create and configure Digital Experience Sites that host React UI bundles on Salesforce. This skill generates the minimum necessary site infrastructure — Network, CustomSite, DigitalExperienceConfig, DigitalExperienceBundle, and the sfdc_cms__site content type — so a React app can be served from Salesforce.

React sites differ from standard LWR sites: they don't need routes, views, theme layouts, or branding sets. The site acts as a thin container (appContainer: true) that delegates rendering to the React UI bundle referenced by appSpace.

Required Properties

Resolve all five properties before generating any metadata. Each has a fallback chain — work through each option in order until a value is found.

The appNamespace and appDevName properties record the intended UIBundle binding for a future follow-up update; they are not substituted into appSpace at initial site creation. appSpace in the sfdc_cms__site content.json is always "" at initial creation — see configure-metadata-digital-experience.md for the reason and the follow-up flow.

Language Properties

The skill always emits sfdc_cms__languageSettings alongside sfdc_cms__site. Resolve defaultLocale for every site (defaults to en_US); resolve languages only when the user requests additional languages beyond the default.

The content-item folder name (languages), title (LanguageContent), and urlName (languagecontent) are fixed Experience Builder auto-defaults — they are not user-authored. See configure-metadata-language-settings.md.

Pre-flight: Target Org Release (Multi-Language Only)

The sfdc_cms__languageSettings content type accepts multi-language declarations only on Salesforce Release 264 (API v68.0 or higher). Sites reduced to a single-locale en_US declaration work on any org and do not need this check.

When the user requests multiple languages, verify the target org's maximum supported API version before writing any metadata. sf api request rest hits /services/data/ on the instance directly and handles authentication at the transport layer, so the org's true ceiling is returned without any access token entering this script's context.

MAX_API=$(sf api request rest "/services/data/" --target-org "${usernameOrAlias}" \
          | jq -r '[.[].version | tonumber] | max')

awk -v v="$MAX_API" 'BEGIN{ exit !(v+0 >= 68.0) }' \
  || { echo "ERROR: multi-language site containers require Salesforce Release 264 (API v68.0+). Target org's maximum supported API version is v${MAX_API}. Retarget to a Release 264+ org, or reduce the site to a single-locale (en_US) declaration." >&2; exit 1; }

If the check fails, do not write metadata. Report the version mismatch to the user and stop.

Generation Workflow

Step 1: Resolve All Required Properties

Determine values for all five required properties and the defaultLocale language property before constructing anything. Use the resolution strategies in the tables above, falling through each option until a value is found. Resolve the languages property only when the user has requested multiple languages — and when they do, run the Pre-flight check above before continuing to Step 2.

Step 2: Create the Project Structure

Use available Salesforce metadata schema and field context for Network, CustomSite, DigitalExperienceConfig, and DigitalExperienceBundle to ensure each file uses valid structure.

Create any files and directories that don't already exist, using these paths:

Each DigitalExperience content-type directory contains only _meta.json and content.json. Both sfdc_cms__site and sfdc_cms__languageSettings are always required inside the bundle. The sfdc_cms__languageSettings default declares only the resolved defaultLocale (e.g. en_US); it is extended with additional languages when the user requests multi-language support. No other content types are permitted.

Step 3: Populate All Metadata Fields

Use the default templates in the docs below. Values in {braces} are resolved property references — substitute them with the actual values from Step 1.

For URL updates, see update-site-urls.md.

Execution Note for Step 3: Load and use the docs

• Agents MUST read the full contents of each references/*.md file referenced in Step 3 before attempting to populate metadata fields.
• Use your platform's file-read tool (for example, read_file) to load these files in full, then perform placeholder substitution for values in {braces} using the resolved properties from Step 1.
• Files to load:
• references/configure-metadata-network.md
• references/configure-metadata-custom-site.md
• references/configure-metadata-digital-experience-config.md
• references/configure-metadata-digital-experience-bundle.md
• references/configure-metadata-digital-experience.md
• references/configure-metadata-language-settings.md