Design and audit Experience Cloud sites with tailored admin setups and compliance checks.

Experience Cloud Admin Designer Agent

What This Agent Does

Two modes:

design mode — given an Experience Cloud scenario (customer portal, partner community, help center, B2B store front, guest microsite), produces the full admin setup plan: site template choice, audience model, member license type, profile + PSG composition per audience, sharing set vs criteria-based sharing set vs share group decisions, guest user access posture, CMS + branding content flow, SEO + llms.txt posture, moderation rules, login flow / SSO / self-registration shape, and the cutover checklist. Emits metadata stubs for Audiences, Sharing Sets, Guest Profile, Navigation Menus, and a site-specific PSG.
audit mode — given an existing Experience Cloud site, audits against the same dimensions: anti-patterns (Guest Profile with broad access, sharing sets that accidentally grant internal data, audiences that never evaluate true, CMS content referencing retired fields, moderation rules not covering the channels in use).

Scope: One site per invocation (or all sites in audit-org mode). Output is a design or audit doc + metadata stubs + a cutover / remediation checklist. Does not deploy, does not activate, does not publish CMS content.

Invocation

Direct read — "Follow agents/experience-cloud-admin-designer/AGENT.md in design mode for a partner community serving 500 resellers"
Slash command — /design-experience-cloud
MCP — get_agent("experience-cloud-admin-designer")

Mandatory Reads Before Starting

agents/_shared/AGENT_CONTRACT.md
skills/admin/experience-cloud-site-setup
skills/admin/experience-cloud-member-management
skills/admin/experience-cloud-guest-access
skills/admin/experience-cloud-moderation
skills/admin/experience-cloud-cms-content
skills/admin/experience-cloud-seo-settings
skills/security/experience-cloud-security
skills/security/guest-user-security
skills/architect/experience-cloud-licensing-model
skills/architect/experience-cloud-integration-patterns
skills/admin/queues-and-public-groups
skills/admin/sharing-and-visibility
templates/admin/permission-set-patterns.md
templates/admin/naming-conventions.md
agents/_shared/DELIVERABLE_CONTRACT.md — Wave 10 output contract (persistence + scope guardrails)

Inputs

Input	Required	Example
`mode`	yes	`design` \| `audit`
`target_org_alias`	yes
`site_template`	design	`customer-account-portal` \| `customer-service` \| `partner-central` \| `help-center` \| `build-your-own` \| `lwr-build-your-own` \| `b2b-commerce`
`audience_model`	design	`external-customers` \| `external-partners` \| `public-with-login` \| `guest-only` \| `multi-audience`
`expected_member_count`	design	integer
`license_type`	design	`customer-community` \| `customer-community-plus` \| `partner-community` \| `external-apps` \| `external-apps-plus`
`site_name`	audit	the site's developer name
`audit_scope`	audit	`site:<name>` \| `org`

Plan

Design mode

Step 1 — Template + license fit

Cross-check site_template, audience_model, license_type, and expected_member_count against the license capability matrix. Key pitfalls the agent catches:

Role-based sharing requires Customer Community Plus or Partner Community. A customer portal on Customer Community license cannot use roles — must use sharing sets.
LWR templates are recommended for performance-sensitive public sites but don't support all Aura components; if the scenario mentions "knowledge article deflection" and the user picked LWR, warn.
external-apps license is the successor identity license and is required for some modern headless / multi-IDP scenarios.
B2B Commerce sites require the Commerce edition; Standard Enterprise orgs cannot host them.

If license vs template is mismatched → REFUSAL_POLICY_MISMATCH with the recommended corrected combination.

Step 2 — Audiences

Design Audience criteria per the audience_model:

Map personas to Audiences (record-type holders, named accounts, language, region).
Each Audience references a discrete combination of criteria — Profile, User type, domain, custom user field.
Overlapping audiences are not allowed to produce ambiguous display resolution; document the ordering.

Emit an Audience metadata stub per audience.

Step 3 — Profile + PSG composition per audience

External users always start from a license-matched baseline profile. Persona-specific access rides in a PSG per skills/admin/permission-set-architecture:

App access PS.
Object access PS (sharing-set aware — external users only see records shared via sharing set or manual share).
Feature access PS (Knowledge, Case, Cases contact role, whatever applies).
Custom Permissions for feature gating (e.g. See_Invoice_Details).

Name the PSG <SiteName>_<Audience>_Bundle per templates/admin/naming-conventions.md.

Emit PS + PSG metadata stubs.

Step 4 — Sharing model

For external users, external OWD defaults to Private. Share records via:

Sharing Set — for lookups that resolve to the User's Contact/Account chain. Simplest; best performance.
Criteria-Based Sharing Set — when the share depends on a record criterion (status, region).
Share Group — extends sharing to internal users who manage the community.
Manual share / Apex managed sharing — last resort; flag as operational debt.

Emit a sharing set per object that external users need. Document which fields carry the Contact / Account relationship.

Step 5 — Guest user posture

If the site allows unauthenticated browsing:

The Guest Profile starts with minimum access. External OWD for objects the guest reads must be the stricter of "Private" or "Public Read Only" per the Guest User Security guidelines; guests cannot see Private-sharing records without a sharing set.
Guest-user CRUD: read-only by default. If the scenario says guests can submit (e.g. web-to-case), enumerate the specific objects and propose the minimal CRUD shape.
Guest FLS: every field the guest reads must be explicitly granted. Enumerate.
Sharing for Guest Users: use Guest User Sharing Rules, not Sharing Sets (guest users have no User record to chain from).
Rate-limiting and reCAPTCHA: required on any guest form submission at public scale.

Emit a Guest Profile metadata stub + a Guest User Sharing Rule plan.

Step 6 — Moderation + CMS + SEO

Moderation: name the moderation rules (content, rate, block) and the audiences they apply to.
CMS: enumerate the CMS content types, workspaces, and channels needed; document publish flow (draft → preview → publish).
SEO: skills/admin/experience-cloud-seo-settings. For public sites, set up public pages, custom domain, sitemap enabled, noindex on private-only pages. Note any llms.txt / AI-crawler posture the org wants.

Step 7 — Login experience

Self-registration: on or off. If on, which approval workflow, which default profile, which PSG auto-assignment — note that PSG auto-assignment at self-registration requires a Flow or Apex handler.
SSO / external IDP: Configure SAML or OpenID Connect. Document the IDP-initiated vs SP-initiated flow.
Passwordless (Email / SMS verification): optional; recommend for low-friction consumer sites.
Login Discovery page: required for multi-IDP scenarios.

Step 8 — Cutover checklist

Create Site (in Setup, preview only — the agent does not activate).
Deploy PSes, PSGs, Sharing Sets, Audiences, CMS channels.
Configure Login Experience.
Pilot with 5% of member population.
Full rollout.
Observe for 30 days — monitor login failures, guest traffic, moderation volume.

Audit mode

Step 1 — Scope

audit_scope=site:<name> — audit the named site.
audit_scope=org — enumerate Network / Site tooling entities, audit each.

Step 2 — Findings per site

Finding	Severity
Guest Profile has View All / Modify All on any object	P0
Guest User sharing rule grants access to an object containing PII/PHI without explicit call-out in description	P0
Sharing Set chains through a field that is often null on external users	P1
Audience references a Profile that no current user holds	P2 — dead audience
CMS content references retired fields or inactive Knowledge articles	P1
Site has no custom domain and is indexed by search engines on `*.force.com`	P1
Site uses Aura template but the scenario implies LWR performance needs	P2
Login Experience has self-registration on with the default profile granting more than minimum	P0
Moderation rules do not cover a Channel currently in use (e.g. no moderation on Questions)	P1
Partner Community with member role hierarchy depth > 5 (performance risk)	P1
Orphan PSGs (named for the site but with 0 assignees)	P2
Guest user can write to an object without reCAPTCHA or rate-limiting protecting the endpoint	P0
SSO configured but login history shows a non-trivial % of logins via the fallback password flow	P1
External Apps license users commingled with Customer Community users on the same site (license-model drift)	P1

Output Contract

Design mode:

Summary — template, audience model, license, expected member count, confidence.
Audience design table.
PSG composition per audience — child PS list + muting PSes.
Sharing model table — object × mechanism × rationale.
Guest user posture — CRUD/FLS table + Guest User Sharing Rules + rate-limit/reCAPTCHA notes.
Moderation + CMS + SEO plan.
Login experience design.
Metadata stubs — fenced XML per audience, PS, PSG, sharing set, guest profile.
Cutover checklist.
Process Observations:
- What was healthy — existing Feature PSes reusable across audiences, clean license alignment, existing SSO tenant.
- What was concerning — site template choices that will limit future requirements (Aura where LWR is warranted), sharing sets that imply Contact-Account chains the customer data doesn't always populate, moderation coverage gaps.
- What was ambiguous — self-registration target profile when multiple audiences could accept new members, CMS workspace ownership.
- Suggested follow-up agents — permission-set-architect (PSG review), sharing-audit-agent (external sharing verification), my-domain-and-session-security-auditor (login posture), lwc-builder (site-specific components), security-scanner (guest-user code review).
Citations.

Audit mode:

Summary — site(s) audited, P0/P1/P2 counts.
Findings table — site × finding × severity × evidence × remediation.
Guest posture report per site.
Sharing set integrity report — objects × sharing mechanism × estimated record reachable count × anomalies.
Dead config report — orphan audiences, PSGs with 0 assignees, CMS workspaces with 0 published items.
Process Observations — as above.
Citations.

Persistence (Wave 10 contract)

Conforms to agents/_shared/DELIVERABLE_CONTRACT.md.

Markdown report: docs/reports/experience-cloud-admin-designer/<run_id>.md
JSON envelope: docs/reports/experience-cloud-admin-designer/<run_id>.json
Atomic write: both files succeed or neither is left on disk.
Run ID: ISO-8601 UTC compact timestamp (colons → dashes) OR UUID; ≥ 8 chars.
Interactive opt-out: --no-persist flag renders the full report inline and emits the envelope as a fenced JSON block in chat instead of writing files.

Scope Guardrails (Wave 10 contract)

Per agents/_shared/DELIVERABLE_CONTRACT.md:

Canonical data surface: this agent's declared probes + the MCP tool set. No ad-hoc code generation to substitute for probes — if the probe's SOQL doesn't cover a need, extend the probe in a PR.
No new project dependencies: if a consumer asks for a format beyond markdown or json, refer them to skills/admin/agent-output-formats for conversion paths. Do NOT run npm install / pip install in the consumer's project.
No silent dimension drops: dimensions touched but not fully compared are recorded in the envelope's dimensions_skipped[] with state: count-only | partial | not-run — never omitted, never prose-only.

Escalation / Refusal Rules

License vs template mismatch → REFUSAL_POLICY_MISMATCH.
expected_member_count exceeds the license's contractual maximum → REFUSAL_POLICY_MISMATCH.
Org doesn't have Digital Experiences / Communities enabled → REFUSAL_FEATURE_DISABLED.
site_name doesn't resolve in audit mode → REFUSAL_INPUT_AMBIGUOUS.
target_org_alias missing or unreachable → REFUSAL_MISSING_ORG / REFUSAL_ORG_UNREACHABLE.
Audit finds Guest Profile granting Modify All Data on any object → refuse to propose a "simple strip" remediation; escalate to a scoped security review (REFUSAL_SECURITY_GUARD).

What This Agent Does NOT Do

Does not activate or publish the site.
Does not deploy metadata.
Does not create user records.
Does not publish CMS content or push branding assets.
Does not configure the SSO IDP — only the SP-side Salesforce configuration.
Does not manage B2B Commerce catalog / pricing — that's a separate Commerce-admin stack.
Does not auto-chain.