Permissions and sharing
Grant necessary access and control operations.
Effective permission and interface
Surface operations check identity, membership and permissions for their scope. Views can hide or explain unavailable Actions, but services remain authoritative. Queries, reference selectors and exports must respect the same reading boundaries.
| Level | Expected value | Responsibility |
|---|---|---|
| Account or organization | Valid identity and membership | Shared context access |
| Workspace and content | Members, roles and grants | Reading and editing |
| Operation | Effective capability and permission | Action execution |
| Plan | Authorized features | Product capabilities |
Personal application access in V2
Sign in to Surface before opening an application or a direct Surface link. The server checks the current session and access to the personal tenant for every read or change. A URL parameter or an application link does not grant access to another tenant. An unavailable or suspended tenant remains inaccessible even when sign-in succeeds.
Use Sign out in the application header to end the session and clear the open application. A revoked or expired session requires signing in again. The public Marketplace is available to Free, Plus, Teams, Pro and Business. Pro or Business provides a private personal Marketplace; Business also provides an organization Marketplace, with current membership and publication role checks. This personal-tenant perimeter does not establish shared-tenant roles; the isolated local review profile does not demonstrate cloud deployment or delivered verification emails.
Team example
Salespeople read and prepare quotes. A manager can approve them. An external reader receives only explicitly shared content. Client links and counts must not reveal quotes the reader cannot know about.
Share and revoke
The Team plan enables collaboration from the user account; it does not create a team or an Organization. Organization is available with Business only. An Organization and the people with access to an individual Workspace are separate scopes.
Open Workspace → Settings → Members and access to inspect members and invitations. Application roles are Owner, Member and Reader. The owner prepares invitations and reviews role changes or access removal before confirmation. The recipient must accept an invitation before receiving its proposed access. Each Space’s read or edit permissions remain separate from the Workspace role; membership does not implicitly grant access to every content item.
Select the object and people, then verify the granted right. A link opens a destination but does not grant permission by itself. Revocation must affect open views and subsequent operations.
In Knowledge settings, Security and access retains the request when its result is unconfirmed. Resume request checks that same invitation or change without creating another one. If the change is already recorded but the list cannot be refreshed, resuming reads access again without repeating the change. A refreshed invitation must be reviewed again before cancellation; cancelling an invitation does not remove any previously accepted access.
For content already shared, the Owner can review missing read access to instructions required by its Model. The review shows the affected people and the number of access contributions to complete. Confirmation completes only the reading of those instructions: it adds nobody to the Workspace and neither creates nor rewrites an invitation. If confirmation remains uncertain, resume the same request; the actual completed count comes from the confirmed result.
Coediting and administration
When adding access is suspended or unavailable, the sharing panel explains this and does not offer a new invitation or role change. The Owner can still inspect access, cancel invitations and withdraw access. An already uncertain request keeps its exact recovery action; current permissions still apply and revoked access is not reactivated.
Before changing a member to Member or Reader, or removing access, the review shows current and proposed effective access for every destination. Direct access and access from other Workspaces are preserved; the last Owner cannot be removed. Member details keep the exact identity when no display name is available. If the response is uncertain, resume the same request from sharing instead of confirming a second change.
Coediting requires Team or higher plus effective session and content authorization. Changing Models, connections or integrations also requires suitable configuration permissions. AI uses its context’s permissions; natural-language requests do not grant extra roles.
Paid plans count every active human member of the account, including Readers, once per account, not once per application or shared Workspace. Unaccepted invitations and inactive identities do not count. Removing access to one application does not remove account membership. Seat counting does not grant access: the application and content permissions still apply.
Applied examples : Preparation and archive permissions
The Space policy requires editor to prepare and owner to archive, in addition to the application role. Command visibility does not replace those permissions.
Configuration
Fragment placed in contentActions[]. Properties and accepted values.
{
"contract": "ContentSpaceActionPolicy@1",
"spaceKey": "clients",
"actionKey": "prepare-quote",
"minimumRole": "editor"
}Variation and connection
Fragment placed in contentActions[]. Properties and accepted values.
{
"contract": "ContentSpaceActionPolicy@1",
"spaceKey": "clients",
"actionKey": "archive-client",
"minimumRole": "owner"
}UI layout example
The illustrative layout below places this configuration in the Clients/Quotes app. Insert each fragment at the stated location, with Field, Query and Action references matching the Model declarations.
- Action
- Minimum role
- Authorized sources
- Decision
editorSubject to accessownerConfirmation requiredSpace permissions combine with the application role and account policy.