XP Access and Permissions — Proposed Model

Proposal — 20 October 2026. Canonical design guidance for Salesforce Admins, Developers and coding agents. Verify installed metadata and enforcement before changing access; this page does not confirm shipped behavior.

Salesforce permissions control authoring. The parent business record, such as a Quote, controls approval. Salesforce records reference hosted content; IDs and URLs grant no authority.

Salesforce records and native permissions

Verify names and fields in the org; subscriber API names usually include rooms__.

Archive preserves records and history. Ordinary Salesforce deletion generally uses the Recycle Bin; permanent deletion is separate. Neither automatically authorizes purging hosted revisions, signed evidence or referenced files.

Three default permission sets

These are proposed starter sets. Evaluate effective permissions, not permission-set labels.

Include required field, Apex class, related-record and File access. Generation requires readable templates and merge data, not template Edit.

Clone the defaults or create custom sets. Permissions accumulate across profiles and assignments: a restrictive clone cannot remove broader grants. A read-only variant omits Create/Edit.

Sharing and ownership

Use native ownership and sharing for record access. Owners still need object and field permissions. Maintain generated-record owners and shares when business ownership changes.

Templates and instances share objects. Give users library-template Read and appropriate instance Edit; give maintainers template-row Edit. Creating or converting a template also requires protected template-classification field access, enforced by authoring services. Generic Create/Edit alone cannot establish this distinction.

Text parent-ID fields inherit neither sharing nor approval locks. Check the parent and XP records; verify sharing defaults in the org.

flowchart TD
    A[User or agent operation] --> B[Effective object and field permissions]
    B --> C[Parent and XP record access]
    C --> D[Draft or release eligibility]
    D --> E[Authorized hosted-content operation]

Keep identity, revision, hash and file-version pointers read-only to ordinary users. Authorized services maintain them and synchronize archive state. Enforce the same caller checks in LWC, API, Flow and agent operations; integration credentials confer no caller authority.

Parent-record approval

Use the parent's Salesforce Approval Process or protected Flow transition. It owns approvers and exceptions; no XP Approver set is required. An editable Approved picklist alone is insufficient.

Approve a package of reviewed business data, exact document/PDF versions and Experience composition. Parent approval does not automatically freeze related XP content. Bind approval to this package; changes for the next release require reapproval. Preserve earlier evidence.

Both Builders can display the parent result. Publisher/Admin access supplies no independent bypass; exceptions require parent-workflow authorization and a recorded reason.

flowchart TD
    A[Generate and personalize draft package] --> B{Parent workflow requires approval?}
    B -- Yes --> C[Submit exact package for parent approval]
    C --> D{Approved?}
    D -- Changes requested --> A
    D -- Yes --> E[Explicit Send]
    B -- No or authorized exception --> E
    E --> F[Recheck authority and package eligibility]
    F --> G[Release recipient access and submit email]
    G --> H[Record each recipient result and EmailMessage]

Send contract

Send submits a recipient-specific email with the authorized, immutable Experience link and approved attachments. All callers use the same release checks.

Record the parent, package, approval/exception, sender, recipient, times, result and EmailMessage. Activity creation, publication and link copying do not prove sending. Report failures and unknown outcomes. Repair missing activity without resending; reconcile uncertain sends before retrying.

External recipients use scoped invitations, not internal permission sets. Archive does not itself revoke invitations or change published versions.

Custom permission sets with coding agents

Canonical machine-readable reference: XP permissions model. Find it through llms.txt or the coding-agent guide.

Give your coding agent this bounded request:

Use this proposed model to draft a custom permission set for my specified users and operations. Inspect authorized org metadata and effective access first. Preserve read-only identity pointers; omit Delete, View All Records and Modify All Records unless requested. Identify required field, Apex, related-record and File access, sharing and parent-approval dependencies. Report missing metadata or enforcement. Present the changes and focused validation plan before applying them.

Permission-set metadata alone cannot configure sharing, approvals, hosted enforcement or delivery. Documentation is design evidence; user authorization and connected-org state govern changes.

Salesforce references

• Object permissions
• Record access and approval locks
• Enhanced Email
• Email submission results