orkiva Before deciding#
- Open Approvals or the Approvals tab on the awaiting run.
- Read the plan, target, resolved source revision and current policy requirements.
- Confirm you are an eligible approver. Protected decisions can require a current MFA-authenticated human session and recent reauthentication.
- Check whether the initiator or source committer is excluded by separation-of-duties rules. Use another eligible person when required.
Record a decision#
- Choose Approve or Reject on the run.
- Enter the reason. Rejection requires a reason; include a concise explanation that the project owner can act on.
- Submit and inspect the recorded decision.
- If multiple approvals are required, wait for the remaining eligible decisions. One approval does not necessarily release the run.
- After the gate opens, follow apply and verification. Approval is permission to proceed, not proof the deployment succeeded.
Stale and rejected decisions#
| Response | What to do |
|---|---|
| stale_approval | Refresh the run. The current plan, target, live-state or policy evidence no longer matches the decision. Review the new evidence. |
| approval_expired | Re-evaluate the policy/plan through the supported run flow. Do not reuse an expired decision. |
| separation_of_duties | Have an independent eligible approver decide. |
| strong_authentication_required | Complete current MFA and recent reauthentication with a human account. |
| approval_already_decided | Inspect the existing decision; repeated submission is not an additional independent approval. |
API-key limitation#
An API key is useful for permitted automation, but it is not a current MFA-authenticated human session. Do not design an automation that silently substitutes an API key for a protected human approval.
Example: an approval that does not release the run#
If a policy requires two eligible approvers, the first approval records one decision; it does not satisfy the entire requirement. Check the recorded decisions and ask another eligible reviewer to inspect the same current plan. The same person submitting again does not create an independent approval.
If the server reports stale evidence, refresh and read the new plan and run details. Do not copy an earlier approval onto a changed plan. If the reviewer is the initiator or source committer and separation of duties excludes them, choose another eligible reviewer rather than changing identities to bypass the check.
A useful rejection reason identifies the object and required correction, for example: “The plan deletes the application Service; preserve it and submit a revised change.” Do not include credentials in the reason.