Approval Workflow
The approval workflow is the mechanism by which Clients formally agree to requirements before development begins. It creates an auditable record of what was agreed, by whom, and when.
How it works
Section titled “How it works”The approval workflow applies to cards that include the Approval component — primarily the built-in Requirement card type.
States
Section titled “States”| State | Meaning |
|---|---|
| Draft | The card is being worked on. No approval has been requested. |
| Submitted | The Provider has submitted the card and is waiting for Client review. |
| Approved | One or more required Clients have approved the card. |
| Rejected | One or more Clients have rejected the card. It returns to Draft. |
The approval process step by step
Section titled “The approval process step by step”1. Assign members to the card
Before a card can enter the approval workflow, it must have at least one team member assigned. Assigned members can be either Providers (responsible for the requirement) or Clients (responsible for approving it).
The approval workflow specifically involves Client members assigned to the card.
2. Submit for approval
When the card is ready for review, the Provider clicks Submit on the card’s approval section. The card moves from Draft to Submitted.
All assigned Client members receive a notification (email and in-app) with a direct link to the card.
3. Client reviews
The Client opens the card in context — inside the spec page, surrounded by all relevant description and rationale. They review the requirement and make a decision:
- Approve — the requirement is confirmed as specified
- Reject — the requirement needs changes
4. Rejection feedback
When a Client rejects a card, they can provide a reason. The card returns to Draft state. The Provider receives a notification, addresses the feedback, and re-submits when ready.
5. Approval
Once all required Client members have approved, the card reaches the Approved state. At this point it is safe to proceed to development.
Who can approve
Section titled “Who can approve”Only Client members assigned to the card can approve or reject it. Providers cannot approve their own requirement cards.
If a Client member is not assigned to a card, they can still read it but cannot participate in the approval decision.
Approval process modes
Section titled “Approval process modes”Cards that include the Approval Process component support two modes:
| Mode | Behaviour |
|---|---|
| Any | The card is approved when any one assigned Client approves it |
| All | The card is approved only when every assigned Client has approved it |
The Provider sets this mode on each card based on how many stakeholders need to sign off.
After approval
Section titled “After approval”Once a card is approved:
- Its state is shown as Approved in the spec page and on any boards it appears on
- It can be synced to Jira as an issue (see Jira Integration)
- It should not be edited without notifying the approving Clients — the change feed will capture any modifications
Auditing
Section titled “Auditing”Every state change in the approval workflow is recorded. The Change Feed for the project shows the full history: who submitted, who approved or rejected, and when.