forcedotcom/sf-skills5 files

Experience Portal Create

Create / provision / set up a NEW Digital Experience (Communities) / Experience Cloud site — employee service, IT support, help desk, HR, customer, and partner portals — via the headless-360 MCP site-creation APIs. Use whenever a user asks to create/provision/set up a portal, site, or community, e.g.: 'create an employee service portal', 'create an IT Support Portal', 'create an Agentforce Employee Center', including wiring MIAW (Messaging for In-App/Web) at create. This is the site-CREATION skill and OWNS provisioning a new Aura OR LWR Experience Builder site from scratch — trigger it even when the user says 'Experience Builder site' or 'LWR site', as long as a NEW site is wanted. It always writes a portal-creation report as its final step (never ad hoc via CLI) and never makes a legacy Tabs+Visualforce site. DO NOT TRIGGER only for modifying an EXISTING site's pages/routes/theme/branding/guest-access metadata (experience-lwr-site-generate), existing-site customization (experience-ui-bundle), CMS, Commerce.

Specification
Skill ID
forcedotcom/sf-skills/experience-portal-create
Publisher
forcedotcom
Repository
sf-skills
Installs
0
Files
5
Synced
Sep 23, 2026
How to use it

Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.

forcedotcom/sf-skills/experience-portal-createInstalls these files
  • SKILL.md
  • assets/report-template.md
  • references/mcp-invocation.md
  • references/post-creation-activate-publish.md
  • references/templates.md

What this skill tells the agent

Create Digital Experience Portal

Create a new Digital Experience (formerly Communities) portal/site in Salesforce. Supports employee service portals, partner portals (PRM), and general customer communities.

Every operation runs through the headless-360 MCP server (mcp__headless-360__discover → mcp__headless-360__describe → mcp__headless-360__dispatch / mcp__headless-360__dispatch_readonly). Do not use the Salesforce CLI (its api request, data query, or org open subcommands), the project-codey MCP server, raw curl, or any other HTTP client — dispatch/dispatch_readonly is the only way this skill talks to the org. See references/mcp-invocation.md for the exact call shapes.

Scope

  • In scope: Creating Digital Experience sites via the headless-360 Connect API dispatcher. Portal type selection. Basic configuration (name, URL, templates). Self-service portals with embedded service configs. Making the site reachable end to end — activating the Network (status: Live), adding member profiles, and publishing the Experience Builder pages (see references/post-creation-activate-publish.md).
  • Out of scope: Deep post-creation customization (page layout/component authoring in Builder). Content authoring. Branding beyond initial setup. Individual per-user record management (membership is added at the profile/permission-set level, not per user).

Execution model (read first)

Every org call is a dispatch: mcp__headless-360__dispatch_readonly(url, method: "GET", queryParams) for reads, mcp__headless-360__dispatch(url, method, body) for writes; read status_code + body from the response. To resolve the endpoint for a portal type, use mcp__headless-360__discover(query=...) and mcp__headless-360__describe(id=...) as needed. Connect API create/list operations for Experience Cloud are not always indexed by discover/describe — when a lookup returns nothing, dispatch the well-known versioned Connect API path directly (see references/mcp-invocation.md) rather than concluding the capability is missing.

Critical: paths must include the full `/services/data/vXX.0/...` prefix (e.g. "/services/data/v67.0/connect/communities") — unlike some other dispatchers, headless-360 does not resolve or inject the API version for you. A path without the version prefix returns 400 ROUTE_NOT_FOUND. Copy the path verbatim from a discover/describe result when available; otherwise use the version shown in this skill's examples (v67.0 at time of writing) and adjust if the org runs a different version. Full details, response envelope, job-monitoring, and gotchas live in references/mcp-invocation.md.


Clarifying Questions

Before proceeding, determine:

  1. Portal type?
  • Employee Service / ITSM / HR / help desk → prefer the `Agentforce Employee Center` Aura template via the communities API (richest employee experience; Agentforce-ready). Use the self-service API instead when MIAW must be wired in at creation time and a guest ESD exists.
  • Partner Portal (PRM) → requires PRM feature enabled
  • Customer Community → general community creation (Aura or LWR Experience Builder template)
  1. Basic settings (required for all types):
  • Portal name?
  • URL prefix? (must be alphanumeric only, no hyphens or spaces)
  • Description (optional)
  1. For Employee Service / Self-Service portals:
  • siteType? → default AURA (Aura Experience Builder + Builder). Use LWR only if the user explicitly wants a Lightning Web Runtime site. Never create a Salesforce Tabs + Visualforce ("VF Template") site — those are legacy and have no Builder.
  • MIAW / Embedded Service Deployment ID(s)? These wire Messaging for In-App and Web into the portal at creation time. A guest ESD config is required by the self-service API; an authenticated-user ESD config is optional. If the user hasn't created an Embedded Service Deployment yet, point them to Setup → Embedded Service Deployments first.
  1. For Partner portals only:
  • PRM template name? (check org-specific templates)

Required Inputs

Employee Service / Self-Service Portals (POST /connect/self-service/site):

  • siteName (required) - portal name
  • guestEmbeddedServiceConfigId (required) - Embedded Service Deployment (MIAW) config ID for guest users
  • embeddedServiceConfigId (optional) - Embedded Service Deployment (MIAW) config ID for authenticated users
  • siteType (optional) - AURA (default) or LWR. Produces an Experience Builder site. Do not use Visualforce.
  • enableForGuest (optional) - whether guest (unauthenticated) users can access the site
  • contentDocumentId (optional) - ContentDocument ID of a logo image to wire into the site's branding set
  • brandColors (optional) - array of RGBA colors targeting action, link, border, text, pageBackground
This API sets the URL path prefix automatically from the site name. There is no templateName — the framework is chosen with siteType (Aura/LWR), never Visualforce.

Partner Portals (PRM):

  • siteName (required)
  • siteUrlPrefix (required)
  • prmTemplate (required)
  • siteDesc (optional)

General Communities (POST /connect/communities):

  • name (required)
  • urlPathPrefix (required) - alphanumeric only, no hyphens
  • templateName (required) - an Experience Builder template. Aura: Agentforce Employee Center (preferred for employee service), Employee Portal, Customer Service, Help Center, Customer Account Portal, Partner Central, Build Your Own. LWR: Build Your Own (LWR), Microsite (LWR). Validate the exact string via GET /connect/communities/templates (see below). Do not use Salesforce Tabs + Visualforce ("VF Template") — it is a legacy Visualforce site with no Builder.
  • description (optional)

Workflow

Step 1: Determine API Based on Portal Type

  1. Employee Service / Self-Service → POST /connect/self-service/site
  • Creates an Aura (or LWR) Experience Builder site — never Visualforce
  • Wires MIAW (Embedded Service Deployment) into the site at creation time
  • Prerequisites: CustomizeApplication permission; org has self-service site-creation API access; a guest Embedded Service Deployment exists
  1. Partner (PRM) → POST /connect/prm/setup/sites
  • Prerequisites: CommonPrmEnabled feature
  1. General Community → POST /connect/communities
  • Uses an Experience Builder templateName (Aura or LWR) — never Salesforce Tabs + Visualforce
  • Prerequisites: Manage Communities permission (ManageNetworks)

Step 2: Create Portal (By Type)

Option A: Employee Service / Self-Service Portal

Use the self-service site API. It creates an Aura Experience Builder site (with the Builder option) by deploying CustomSite, Network, and ExperienceBundle metadata, then wires MIAW into the site via the given Embedded Service Deployment (ESD) config IDs. This is the correct path for ITSM / IT help desk / employee self-service portals.

API Call (via mcp__headless-360__dispatch):

method: "POST"
url:    "/services/data/v67.0/connect/self-service/site"
body:
{
  "siteName": "<portal-name>",
  "siteType": "AURA",
  "guestEmbeddedServiceConfigId": "<guest-ESD-config-id>",
  "embeddedServiceConfigId": "<auth-ESD-config-id>",
  "enableForGuest": true
}

Poll with GET /services/data/v67.0/connect/self-service/site/status/{jobId} via mcp__headless-360__dispatch_readonly.

  • siteType defaults to AURA (Aura Experience Builder + Builder). Pass LWR only if the user explicitly asks for a Lightning Web Runtime site. Never create a Visualforce site.

More from forcedotcom

Use this skill in a project

Open any RiverX project, search the Skills panel for forcedotcom/sf-skills/experience-portal-create, and install it in one click.

Use this skill