Recipe Approval Workflow

The workflow defines the states a recipe version traverses and the rules for each transition. A minimal compliant workflow is:

1. Draft — author drafts; freely editable; no execution allowed.
2. Submit for Review — author locks the version; routes to reviewer queue.
3. Under Review — independent reviewer challenges; can request changes or sign.
4. Pending QA Approval — reviewer signed; routes to QA approver queue.
5. Approved — QA signed; version is immutable.
6. Active — eligible for use in new work orders.
7. Superseded / Obsolete — terminal states.

21 CFR 211.186 requires "prepared by one person and independently checked by a second". Annex 11 §15 adds change control with appropriate approval. The workflow must enforce:

• Author ≠ Reviewer — same human cannot occupy both roles.
• Reviewer ≠ QA Approver — three distinct humans (typically, though Reviewer and QA can be the same in smaller orgs with explicit policy).
• Author cannot self-approve via role-switching.
• Reviewer rejection sends the version back to Draft with the rejection rationale captured.
• QA rejection sends back to Reviewer (or Draft) with rationale.
• Approval cannot be retroactive — timestamps must reflect actual signing time.

Part 11 §11.200 requires every e-signature to capture:

• Printed name of the signer (resolved from the authenticated session).
• Date and time of execution (server time, not client clock).
• Meaning — "Prepared by", "Reviewed by", "Approved by", with the specific recipe scope.
• Two distinct identification components for the first signing in a session (e.g. password + biometric, or password + one-time code).
• Re-authentication for subsequent signings in the same session — V5 prompts for password again at each signing event.

The signed artefact (the recipe snapshot) is bound to the signature so it is computationally impossible to copy a signature to a different recipe or version.

A good reviewer experience reduces approval risk and saves hours per recipe. The reviewer should see:

• Field-level diff between this version and the previously Active version.
• The change-control rationale and impact assessment.
• The descendant impact — which Master Recipes / SKUs / sites are affected.
• Linked CAPA / deviation / regulatory supplement that triggered the change.
• Validation evidence linkage — what re-validation has been done or is required.
• Training-delta preview — which roles need refresher training.

Reviewers who see only "open the new version PDF and compare with the previous PDF" miss changes and sign with false confidence.

The QA approver is not a second reviewer. Their role is to verify:

• Change control is complete and signed.
• Validation linkage is satisfied (no "validation pending" hanging).
• Regulatory pathway is correct (PAS / CBE-30 / annual report decision documented).
• Training plan is in place; effective date allows the training window.
• The recipe complies with the company's quality manual and the relevant regulatory file.

QA approval is also the gate where the version's Effective Date is set — not necessarily "now". A recipe may be Approved on May 15 but not Effective until June 1, allowing training, regulator notification, or coordinated site rollout.

• Parallel drafts — multiple Draft versions are allowed; only one can become Active at a time.
• Rebase — if Draft v3 is in review and v2 becomes Active, v3 must be re-based against v2 before continuing.
• Rollback — an Active version that turns out to be defective triggers a new version (often returning to a prior content) plus a CAPA. Direct rollback by re-activating an older version is allowed only via an emergency-revocation workflow with QA + Head of Manufacturing + Head of QA signatures.
• Hot-fix — emergency new version with expedited review; rationale must explicitly invoke the emergency pathway.

• Author and reviewer the same human (small teams; failure to enforce role separation).
• Reviewer signs without a diff — sees only the new version, signs by default.
• QA approver acts as second reviewer instead of governance check.
• Effective Date = approval date always — no coordinated rollout.
• No rebase enforcement — Draft v3 silently overwrites Active v2 changes.
• E-signature meaning generic ("signed") instead of specific ("approved as QA for recipe X v3").
• Re-authentication skipped for subsequent signings — Part 11 §11.200 violation.
• Rejection rationales not required — reviewer rejects with no reason captured.
• Workflow rules only in UI, bypassable via API.