Approval Workflow Guide
Synced from repo docs
This page is synced from docs/guides/approval-workflow-guide.md via docs/public-docs.json. Edit the owning repo source instead of this generated copy. GitHub source: https://github.com/byteor-systems/byteor-cloud/blob/master/docs/guides/approval-workflow-guide.md
ByteOr Cloud uses approval coverage to gate risky deployment and replay actions.
When approvals matter
Approvals are required when the target environment posture or action type demands governed execution.
Typical cases include:
- production deployments
- execute-mode replay against governed environments
- actions that require named capabilities or policy coverage
Core operator flow
- Prepare the pipeline version and config bundle.
- Start the deployment or replay action.
- Review the environment, spec hash, and required capabilities.
- Select an eligible approval or obtain one from an authorized reviewer.
- Submit the action with the approval attached.
- Confirm the audit trail records the actor, scope, and decision.
What the platform validates
Approval verification rejects requests when any of the following are true:
- the signing key is unknown
- the signature is invalid
- the approval does not match the spec hash
- the approval targets the wrong environment
- the credential has expired
- the capabilities are insufficient for the requested action
These rejection paths are covered in backend test suites and should remain release blockers for future approval changes.
Deployment guidance
Before approving a deployment, verify:
- the pipeline version is the expected canonical build
- the config bundle matches the intended environment
- the deployment target environment is correct
- the approval scope covers the deployment action
Replay guidance
Execute-mode replay reuses deployment-style approval coverage checks. Reviewers should confirm:
- the source artifact came from the expected environment
- the resolved pipeline version matches the incident spec hash
- the approval scope is valid for replay execution
Dry-run replay can still be used for investigation without granting execute privileges.
Audit expectations
Approval-sensitive flows should create audit records that make it possible to answer:
- who initiated the action
- what environment and project were affected
- whether approval was required
- which approval was provided
- which capabilities were required
Operator checklist
- verify environment and project before requesting approval
- verify the spec hash or version being approved
- prefer short-lived approvals over broad standing coverage
- use dry-run replay first when investigating incidents
- review audit records after high-risk actions