Quorum Approval (Deployment)
What this screen is for
This screen turns on two-person control for the deployment: quorum (M-of-N) approval of the deployment's own policy changes. With it on, an operation it gates changes nothing when a platform administrator asks for it. The request waits, and the operation runs only when M platform administrators other than the one who asked have approved it. Here you set the deployment policy, and you decide the platform requests that wait for you, the recovery of a tenant's policy among them.
The deployment policy is off by default, and it is separate from every tenant's own policy.
What must exist first
- The permission to read the deployment's quorum policy shows this screen. To change it you need the permission to manage it; to approve or reject, the platform approve permission; to withdraw your own request, the cancel permission.
- Enabling needs M + 1 eligible platform approvers: active platform administrators holding the platform approve permission, because a requester never approves their own request.
Decisions you make here
Turning it on, and what it gates
Set the approvals a request needs (1 to 10, never counting the requester), how long a request may wait (1 to 336 hours), and the operations to gate: changing the deployment lifecycle, algorithm or rotation policies, allowing a tenant to override the deployment policies, and the platform recovery of a tenant's policy.
Changing the quorum policy itself and making someone a platform approver are always gated once the policy is on.
While the deployment policy gates a policy, the bulk write of all the deployment policies at once is refused and writes nothing: change each policy on its own, so the approvers decide it.
Changing it or turning it off
Once on, the policy guards itself: changing it or turning it off waits for the approvers like any other request.
Deciding platform requests
The requests list opens on the ones that are Pending, with the operation, its target, who asked for it, the approvals it holds and when it expires. Approve counts your approval, and the approval that reaches the quorum runs the operation as the administrator who asked for it. Reject ends the request. Withdraw is offered on your own pending request only.
Approving, rejecting, and changing, turning off or recovering the policy ask for a recent confirmation of who you are. If you last confirmed it more than a few minutes ago, Confirm your identity to continue opens with your own sign-in steps; once you confirm, your decision is sent. Nothing is recorded until then.
Recovering a tenant's degraded policy
A tenant's policy is degraded when it has fewer approvers than it needs, so a request there may never reach its approvals. A platform administrator may ask to recover it, giving a reason; the request waits here like any other.
Once a second platform administrator approves it, the recovery is Scheduled: the tenant's administrators are notified, and it takes effect 72 hours later unless a tenant administrator cancels it. When it takes effect the tenant's policy is deleted, its waiting requests are cancelled, and the deletion is recorded in the tenant's own audit trail with the reason.
A healthy policy cannot be recovered: the tenant changes it through its own quorum.
How it relates to other screens
The quorum entry on the Platform Policies hub shows the deployment policy's state and how many requests wait:
On any other platform screen, an operation the policy gates is shown as waiting for approval, with a link to its request here, never as a failure.