End-to-End Requirement Approval
This guide walks through the complete approval cycle for a single requirement — from the moment the Provider creates the card to the moment it is approved and ready for development.
Prerequisites
Section titled “Prerequisites”- A project exists with at least one Provider and one Client
- A spec page exists for the feature being described
Step 1: Provider writes the spec
Section titled “Step 1: Provider writes the spec”The Provider writes the surrounding context in the spec page — the feature description, user story, business rationale, and any relevant constraints. This is the content that will help the Client understand what they’re being asked to approve.
A well-written spec page means the Client doesn’t need to ask “but why are we building this?” when they see the card.
Step 2: Provider creates a requirement card
Section titled “Step 2: Provider creates a requirement card”Within the spec page, the Provider inserts a Requirement card by typing / and selecting the Requirement type from the block menu.
The Provider fills in:
- Title — a clear, concise statement of the requirement (e.g. “Users can reset their password via email”)
- Type — the category of the requirement (Feature, Bug, Enhancement, etc.)
- Members — adds the relevant Client(s) who need to approve this card, and any Provider members responsible for it
Step 3: Provider configures the approval process
Section titled “Step 3: Provider configures the approval process”If multiple Clients are assigned, the Provider sets whether any or all assigned Clients must approve for the card to be considered approved.
For critical requirements, “all” is appropriate — every named stakeholder must sign off. For lower-stakes items, “any” is sufficient.
Step 4: Provider submits the card
Section titled “Step 4: Provider submits the card”When the card is ready for Client review, the Provider clicks Submit on the card’s approval section.
- The card moves from Draft to Submitted
- All assigned Client members receive an email notification and an in-app notification
- The notification includes a direct link to the card in context
Step 5: Client reviews the card
Section titled “Step 5: Client reviews the card”The Client clicks the notification link and lands on the spec page, with the card in view. They read the requirement in context and make their decision.
If approved: The Client clicks Approve. The card moves to Approved state. Provider members assigned to the card are notified.
If rejected: The Client clicks Reject and enters a reason. The card returns to Draft. The Provider is notified and can see the rejection reason on the card.
Step 6: Provider addresses feedback (if rejected)
Section titled “Step 6: Provider addresses feedback (if rejected)”The Provider reads the rejection reason, updates the spec page and/or card content to address the Client’s concern, and re-submits the card. The cycle repeats until the Client approves.
Step 7: Approved card moves to development
Section titled “Step 7: Approved card moves to development”Once approved, the requirement is ready for development. The Provider (or project manager) syncs the card to Jira — a Jira issue is created linked to the card. The card then appears on the board in the “Approved” or “In Development” column.
Development work proceeds based on the approved spec. The Jira issue links back to the Vanillaround card, so developers can always find the source spec for any ticket they’re working on.
What the audit trail shows
Section titled “What the audit trail shows”At any point after this process, the changes feed shows:
- When the card was first created
- When it was submitted (and by whom)
- When it was approved or rejected (and by whom)
- Any subsequent modifications to the card or spec
This trail is the formal record of agreement between Provider and Client.