Approvals and releases
When work clears QA it becomes a release candidate. Before it reaches Production it collects the approvals your organisation requires, and an admin promotes it. This page covers the release board, approval rules, readiness and promotion.
Release candidates
Section titled “Release candidates”Any app, module, submodule or task in Ready to Ship is a release candidate. Items already in Production or Deprecated stay on the board for history.
The release board lives in:
| Workspace | Location |
|---|---|
| Admin | Tasks → Release |
| Product Manager | Release tab |
| Client | Releases tab (decides Client Approved) |
| UI Designer, Viewer | Releases tab (view only) |
Filter candidates by entity type, readiness, approval type, approval status, release version, approval gaps (missing approvals or none), due state (overdue approvals) and release state (production ready, needs action, overridden).
Selecting a candidate shows its readiness panel, approval checklist, approval history, and collaboration panel (activity timeline, status history and comments).
Readiness
Section titled “Readiness”QA Sync scores each candidate from 0 to 100. The score starts at 100 and drops for risk: priority, missing approvals, incomplete dependencies, failed QA, blocked items, overdue items and an explicit blocked flag.
| Readiness | When |
|---|---|
| Not Ready | The item isn’t in Ready to Ship or Production. |
| At Risk | It is, but something is missing: an approval, a dependency, or there’s failed QA, a blocked item or overdue work. |
| Ready | Nothing is missing. |
| Approved for Release | Nothing is missing and the item has a required Admin Approved approval that has been approved. |
Ready and Approved for Release count as production ready.
Approvals
Section titled “Approvals”Approval types
Section titled “Approval types”| Type | Who can decide it |
|---|---|
| Developer Approved | Admins, and Developers on tasks (not their own task unless the rule allows self-approval). |
| QA Approved | Recorded automatically from QA runs (see below). Admins and Testers can also decide it. |
| Product Manager Approved | Admins, and Product Managers on items in Ready to Ship or Production. |
| Admin Approved | Admins. |
| Client Approved | Admins, and Clients on items in Ready to Ship or Production in apps they can access. |
| Security Approved | Admins. |
| Compliance Approved | Admins. |
QA Approved comes from QA runs
Section titled “QA Approved comes from QA runs”Testers don’t record QA Approved by hand. When a tester submits a QA run on a task:
| QA result | QA Approved becomes |
|---|---|
| Passed | Approved, by the tester who ran QA. |
| Failed | Rejected, with the tester’s notes as the rejection reason. The task also returns to In Progress. |
| Blocked | Unchanged. |
A later passing run (for example the retest after a fix) approves it again.
Approval statuses
Section titled “Approval statuses”| Status | Meaning |
|---|---|
| Pending | Waiting for a decision. |
| Approved | Signed off. |
| Rejected | Turned down. A rejection reason is required. |
| Skipped | No rule asks for it any more. Set automatically when rules change; it returns to Pending if a rule asks for it again. An approval that was already Approved stays Approved. |
Approvals from an optional rule show an Optional badge. They can be decided like any other, but never count as missing and never block a release.
Decide an approval
Section titled “Decide an approval”Product Managers and Clients see a Waiting on you list above the release board with every approval their role decides, each with Approve, Reject (a reason is required) and Review, which opens the candidate on the board. The Release (or Releases) tab shows how many are waiting.
From the board:
- Select the candidate on the release board.
- In the approval checklist, find the approval. If your role can decide it, you’ll see the actions.
- Select Approve, or enter a reason and select Reject.
Readiness recalculates straight away, and the decision is added to the approval history, the audit log and the relevant people’s notifications.
Approval rules
Section titled “Approval rules”Approval rules decide which approvals each item needs. Admins manage them in the Approval Requirements panel at the bottom of the admin release board.
A rule has:
| Field | Meaning |
|---|---|
| Entity type | App, module, submodule or task. |
| Approval type | One of the seven types above. |
| Work type, Priority, Release version | Optional filters. Leave blank to apply to all. |
| Required approval | Required or optional. |
| Allow self approval | Whether the person who did the work may approve it. |
| Sort order, Notes | Display order and explanation. |
Default rules:
| Entity | Approval | Applies to | Required |
|---|---|---|---|
| Task | QA Approved | all tasks (recorded from QA runs) | yes |
| Task | Admin Approved | Critical-priority tasks | yes |
| Task | Admin Approved | Hotfix tasks | yes |
| Submodule | Product Manager Approved | all | yes |
| Module | Product Manager Approved | all | yes |
| App | Product Manager Approved | all | yes |
| App | Admin Approved | all | yes |
| App | Client Approved | all | optional |
When you add, change or delete a rule, QA Sync recalculates readiness for affected items.
Promote to Production
Section titled “Promote to Production”Only Admins can promote.
When the candidate is ready
Section titled “When the candidate is ready”- Select the candidate.
- Select Promote To Production.
- Review the summary and select Promote to production.
The item moves to Production, and QA Sync records who released it and when.
When the candidate isn’t ready
Section titled “When the candidate isn’t ready”- Select the candidate. The board shows Production override required.
- Write why you’re releasing despite the outstanding risk.
- Select Promote With Override and confirm.
The override reason, who made it and when are stored on the item and in the audit log. Overridden releases can be filtered on the board and are counted on the admin Overview.