Scopes and access
Scopes describe operations, not broad organizational roles. A grant succeeds only when the client, App entitlement, installation, environment, and scope are all currently active.
Scope model
Scopes are App-qualified strings such as vision.apps:read, platform.publications:read, crm:today:read, and calendar:agenda:read.
Platform scopes
- Name
vision.apps:read- Description
Read the installed App catalog available to the client.
- Name
vision.organization.basic:read- Description
Read the bounded organization context.
- Name
platform.publications:read- Description
Retrieve an active allowlisted publication projection.
CRM scopes
| Scope | Capability family |
|---|---|
crm:today:read | Attention queues and current actor/workload context |
crm:intake:read | Quarantined intake queue and detail |
crm:intake:review | Controlled intake-review commands |
crm:people:read / crm:people:write | Canonical people reads and controlled commands |
crm:organizations:read / crm:organizations:write | Organization reads and controlled commands |
crm:opportunities:read / crm:opportunities:write | Pipeline, funnel, detail, and controlled commands |
crm:tasks:read / crm:tasks:write | Assigned work and controlled task commands |
crm:search:read | Authorized cross-resource CRM search |
One polymorphic CRM command operation declares the specific write scopes it may require based on command type. Possessing one write scope does not grant every CRM mutation.
Calendar scopes
| Scope | Capability family |
|---|---|
calendar:health:read | Authenticated readiness |
calendar:actor:provision | Provision or reactivate an actor binding |
calendar:agenda:read | Visibility-filtered agenda |
calendar:event:read / calendar:event:write | Event details and event commands |
calendar:availability:read | Availability and multi-actor open-slot calculation |
calendar:conflict:read | Conflict checks without private record details |
calendar:attendance:write | Invitation response commands |
calendar:recurrence:write | Materialized occurrence commands |
calendar:hold:write | Create or release expiring scheduling holds |
Availability access does not imply permission to read event details. Conflict responses are deliberately bounded to avoid leaking private calendar content.
Accounting scopes
Accounting separates health/actor/overview reads; counterparty reads and writes; invoice reads and draft operations; approval preparation; settings reads and writes; provider reads and connection; and import creation, reading, upload, mapping, and validation.
The approved scope names are rendered on each Accounting operation. Provider connection, invoice drafting, approval preparation, and import validation are distinct capabilities; do not collapse them into one broad financial-write grant.
Authorization layers
A request can be denied at any of these layers:
- Client or credential version inactive.
- Token signature, issuer, audience, time, or vocabulary invalid.
- App not installed or entitlement absent.
- Workspace binding inactive or mismatched.
- Required operation scope absent or revoked.
- Identity class or human/service role not permitted.
- Record not visible in the workspace or actor context.
- Resource state or business invariant prevents the action.
A 403 does not identify which private policy object failed. A 404 may intentionally avoid confirming whether a record exists.
Least privilege
Request only the scopes needed for the immediate token. Asking for an ungranted scope fails the complete exchange; Vision does not silently reduce the request.
Use separate clients for separate services and environments. Review grants when an integration changes purpose, an employee or service owner changes, an App is removed, or a credential is rotated. Revoke unused grants rather than keeping them for convenience.