| name | experience-ui-bundle-site-generate |
| description | MUST activate when the project contains a uiBundles/*/src/ directory and the task involves creating or configuring site infrastructure. Use this skill when creating or configuring a Salesforce Digital Experience Site for hosting a UI bundle. Activate when files matching digitalExperiences/, networks/, customSite/, or DigitalExperienceBundle exist and need modification, or when the user wants to publish, host, or configure guest access for their app. Also use this skill to add multi-language, multi-locale, internationalization, or translation support to such a site by declaring a default locale and additional supported languages via the sfdc_cms__languageSettings content type. DO NOT TRIGGER for LWR (non-React) sites; use experience-lwr-site-generate instead. |
| metadata | {"version":"1.3","domains":["Experience"],"minApiVersion":"65.0","relatedSkills":["experience-lwr-site-generate"],"cliTools":[{"tool":"[Truncated]","semver":">=1.0"},{"tool":"[Truncated]","semver":">=1.6.0"},{"tool":"[Truncated]","semver":">=2.0.0"}]} |
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.
| Property | Format | How to Resolve |
|---|
| siteName | UpperCamelCase (e.g., MyCommunity) | Ask user or derive from context |
| siteUrlPathPrefix | All lowercase (e.g., mycommunity) | User-provided, or convert siteName to all lowercase with alphanumeric characters only |
| appNamespace | String | namespace in sfdx-project.json → sf data query -q "SELECT NamespacePrefix FROM Organization" --target-org ${usernameOrAlias} → default c |
| appDevName | String | UIBundle metadata in the project → sf data query -q "SELECT DeveloperName FROM UIBundle" --target-org ${usernameOrAlias} → default to siteName |
| enableGuestAccess | Boolean | Ask user whether unauthenticated guest users can access site APIs → default false |
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.
| Property | Format | How to Resolve |
|---|
| defaultLocale | xx or xx_YY (e.g., en, en_US) | Ask user → default en_US |
| languages | List of {label, locale} | Only when the user asks for multiple languages, locales, internationalization, or translation support: ask for the additional languages the site supports. When not requested, the languageSettings content declares only the resolved defaultLocale as a single-language entry. |
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:
| Metadata Type | Path |
|---|
| Network | networks/{siteName}.network-meta.xml |
| CustomSite | sites/{siteName}.site-meta.xml |
| DigitalExperienceConfig | digitalExperienceConfigs/{siteName}1.digitalExperienceConfig-meta.xml |
| DigitalExperienceBundle | digitalExperiences/site/{siteName}1/{siteName}1.digitalExperience-meta.xml |
| DigitalExperience (sfdc_cms__site) | digitalExperiences/site/{siteName}1/sfdc_cms__site/{siteName}1/* |
| DigitalExperience (sfdc_cms__languageSettings) | digitalExperiences/site/{siteName}1/sfdc_cms__languageSettings/languages/* |
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.mdreferences/configure-metadata-custom-site.mdreferences/configure-metadata-digital-experience-config.mdreferences/configure-metadata-digital-experience-bundle.mdreferences/configure-metadata-digital-experience.mdreferences/configure-metadata-language-settings.md
- Read entire file contents, replace placeholders (e.g.
{siteName}) with the resolved values, then use the expanded templates to populate the metadata XML/JSON content.
Step 4: Do Not Modify Non-Templated Properties
Do not modify any default property values for Network, CustomSite, DigitalExperience, DigitalExperienceConfig, or DigitalExperienceBundle metadata that are not expressed as variables wrapped in {braces}.
Verification Checklist
Before deploying, confirm:
sf project deploy validate --metadata Network CustomSite DigitalExperienceConfig DigitalExperienceBundle DigitalExperience --target-org ${usernameOrAlias}
Common Workflows
Updating Experience Site URLs
Use when user wants to update or change site URLs (urlPathPrefix).
Steps:
Configuring Multi-Language Support
Use when user wants the site to support multiple languages, locales, internationalization, or translation — beyond the default-locale-only declaration that every site already receives.
Steps:
Note: This is authoring-only — declared locales deploy cleanly, but locale-in-path routing does not resolve at request time yet. Do not translate the UI bundle content itself; this only declares the site's supported languages.
