How approval policy turns a sensitive mutation into a queued request, who may decide it, and how it differs from deployment and access approval.
Change approvals
Approvals is the organization-wide inbox for ordinary platform and infrastructure changes that policy requires another person to review. It is separate from the deployment approval list on Pipelines and from Waiting for you on Access requests; each queue represents a different workflow.
What can be gated
Policies use six understandable classes rather than hundreds of individual operations:
| Class | Covers |
|---|---|
| Provision | Creating infrastructure |
| Configure | Changing provider or platform settings |
| Deploy | Shipping code or editing deployment automation |
| Destroy | Deleting something or making it unrecoverable |
| Access | Roles, credentials and network exposure |
| Data | Moving, overwriting or destroying data |
Organization-level policy covers changes to the tenant itself, including members, roles, teams, ownership, branding and organization deletion. Project and environment policy lives under Organization → Projects → Manage → Approvals and covers work inside that project. The policy screen also lists routes that are deliberately never gated, so enabling every available switch does not imply every request in the product waits for approval.
Production deployment approval is always on and cannot be disabled by this policy.
What happens to a gated change
The original action does not run. xAuto stores a request with a business-language summary, the affected project and environment, its change class, requester and expiry. Sensitive values are redacted; the reviewer is told that a secret is involved but never shown it.
An eligible person opens Waiting on me and approves or rejects it. The requester cannot approve their own change, rejection requires a reason, and two decisions racing each other cannot both win. Approval replays the original action in the background; the request remains the place to watch until that replay succeeds or fails.
The requester uses My requests to follow the outcome or withdraw a still-pending request. Both sides receive the configured notifications.
Choosing approvers
For project work, eligibility follows the most specific configured list: environment, then project, then anyone holding the relevant approval permission. Lists can name individual members or teams. Organization changes use the organization policy and eligible organization approvers.
Do not use change approval to grant temporary access. Access request types know how to provision and later withdraw a credential or scope grant; the generic change queue deliberately does not.