---
isPublished: true
template: "page.peb"
title: "XP Access and Permissions — Proposed Model"
displayName: "XP Access and Permissions"
description: "Proposed Salesforce access model for XP documents and Experiences: three default permission sets, native permissions, parent approval and controlled sending."
category: "support"
contentType: "reference"
audience: "admin,developer"
tags: "salesforce,xp,permissions,sharing,approval,documents,experiences,coding-agents"
section: "support"
seoTitle: "XP Permissions and Sharing Model for Salesforce"
seoDescription: "Plan XP User, Publisher and Admin access using Salesforce CRUD, field permissions, sharing, parent-record approval and an auditable Send operation."
llms: true
llmsSection: "Build Developer"
llmsTitle: "XP Permissions and Sharing — Proposed Model"
llmsDescription: "Canonical proposed XP access model for custom permission-set design. Three default sets, native CRUD/FLS/sharing, parent approval and Send. Verify installed metadata and enforcement."
llmsOptional: false
llmsOrder: 30
---

**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

| Content | Salesforce access record |
| --- | --- |
| Document templates and generated documents | `Content__c` |
| Experience templates and generated Experiences | `DocumentRoom__c` |
| Experience items, members and review/publication requests | `DocumentRoomItem__c`, `DocumentRoomMember__c`, `RoomRequest__c` |

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

| Native permission | Proposed XP behavior |
| --- | --- |
| Read | List, open and preview content the user can access. |
| Create | Generate a persisted document or Experience and its Salesforce record. |
| Edit | Modify an accessible draft, including its hosted content. |
| Edit plus writable `IsArchived__c` | Archive or restore accessible content through the controlled operation. |
| Delete | Permit record deletion, subject to lifecycle and retention rules. |
| View All Records | Read all rows of that object regardless of sharing; separate parent access still applies. |
| Modify All Records | Administer rows of that object regardless of sharing; release and integrity rules still apply. |
| View All Fields | Read all fields; grants no field-write authority. |

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.

| Default set | Instance access | Template access | Administration |
| --- | --- | --- | --- |
| **XP User** | Read/Create/Edit; archive/restore; no Delete, View All Records or Modify All Records. | Read/use approved templates. | None. |
| **XP Publisher** | User capabilities. | Create, maintain and publish authorized templates, with required field and record access. | No general administration. |
| **XP Admin** | Required XP record administration and repair. | Required template administration. | Configuration; Delete, View All Records and Modify All Records only where necessary. |

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.

```mermaid
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.

```mermaid
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.

| Fact | Required meaning |
| --- | --- |
| Approved or exempt | The parent workflow authorizes this exact package, or records an allowed exception. |
| Recipient access | Invitation and publication access match the authorized recipient and package. Copying a live link must pass the same release gate. |
| Sent | Salesforce accepted the email submission for that recipient and the sending transaction committed. |
| Salesforce activity | An associated `EmailMessage` records the email. Require Enhanced Email and the applicable package logging configuration before Send. |
| Delivered or opened | Separate observed outcomes; neither follows merely from Sent. |

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](https://www.idialogue.app/content/support/xp-permissions.md). Find it through [llms.txt](/llms.txt) or the [coding-agent guide](/build/index.html).

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](https://help.salesforce.com/s/articleView?id=users_profiles_object_perms.htm&language=en_US&type=5)
- [Record access and approval locks](https://help.salesforce.com/s/articleView?id=000385161&language=en_US&type=1)
- [Enhanced Email](https://help.salesforce.com/s/articleView?id=emailadmin_enhanced_email_considerations.htm&language=en_US&type=5)
- [Email submission results](https://developer.salesforce.com/docs/platform/api/guide/sforce-api-calls-sendemail-emailresult.html)