How access is decided
Effective access combines the signed-in identity, active membership, current module entitlement, assigned user types/direct permissions, explicit personal blocks, the record's scope and business policy guards. Navigation is filtered by that result; the server checks it again for reads and changes.
| Control | What it changes |
|---|---|
| Product switch | Whether a business has a work area enabled. It does not grant a person permission. |
| Membership | Whether a person is active in the business or Group. Suspending membership removes that reach even if grants remain recorded. |
| User type | A reusable, versioned set of capabilities and allowed scopes. Several types can contribute to one person. |
| Direct permission | An explicit positive grant for an operation and place/time scope. |
| Personal block | A restriction that wins over positive direct or inherited grants in its scope. |
| Delegation | Whether the administrator may pass on that authority. Holding a permission does not always make it delegable. |
| Policy guard | Additional checks such as consent, approved spending, source freshness or a second approver. |
Full access is a summary of standard administrator coverage across the currently enabled work areas in that business without active personal restrictions. It does not mean platform operator access, every specialist capability, or automatic access to future products. Custom access and No current access describe narrower effective results. Removing one grant may leave another positive source; the effective view and winning blocks explain that outcome.
Scopes include Group (portfolio), legal entity (organization), Brand, Site
(venue), Space, Series, Event, own record and assigned record. A permission
catalogue's allowed scopes are not a grant to every record at those scopes.
Sensitive seller operations may additionally require direct seller membership.
Invite or change a person's access
- Open Settings → People & access. Search the person and review their effective access, place, duration, contributing user types and restrictions.
- For existing people, edit the work-area switches and expand individual permission switches where needed. Advanced controls retain exact scopes, dates, user types, delegation and explicit blocks.
- Review the draft additions, restorations and removals. A work-area switch changes that person's access in this business; it does not buy/enable the product or rewrite the Group responsibility.
- Acknowledge sensitive changes, give the required reason and save. Current authority and the reviewed state are rechecked before the batch applies.
- For a new recipient, use Invitations to choose the user type, modules, scope, access end date and reason. The recipient-bound invitation has no authority until accepted at its access link. Withdraw an unused invitation explicitly when it is no longer needed.
Turning a person's work area off creates a local restriction over their direct and inherited reach. Restoring it preserves the editor's existing scope and expiry where applicable; it does not invent broader permission. Suspended memberships must be restored before new responsibilities can take effect. Changes remain drafts until review/save; a stale or denied save is not success.
The User types surface can create a profile or a new immutable revision, including starting from a person's reusable positive permissions. It excludes personal blocks and does not keep the profile synchronised with that person. Review impact before applying a new revision to selected or all assignments; publishing the revision alone does not silently update existing people.
Some existing businesses retain legacy or shadow access migration modes. Shadow mode still enforces legacy authority while recording comparisons; capability mode uses the new resolver. The access migration controls and verification are a deliberate administrative transition, not an automatic effect of creating a user type.
Enable or disable a product
Open Settings → Modules, change the relevant switches, choose Review changes, inspect the enable/disable list, supply a reason, then apply. The screen requires both organisation-settings and module-management permission to change products; it prevents removing the last selected product. Existing authorised Group access can apply through valid bindings, while personal access is managed separately.
Disabling removes work-area reach and retires its current entitlement incarnation. Historical evidence remains under its retention/access rules. Re-enabling does not restore retired personal assignments automatically. Review the person's effective access again. Paused providers, missing connections and rollout controls can still make individual operations unavailable within an enabled product.