Approval Workflow

The approval step is where authorized decision-makers review a change request along with its impact assessments and render a formal decision. The approval decision determines whether the change proceeds to implementation, is rejected, or is conditionally approved with additional requirements.

Before you can approve

An approval decision can only be recorded once the change request has been submitted for review. A change still in draft must be submitted first (see Submitting changes).

Submit an approval decision

1. On the left sidebar, select Change Control.
2. Select the change request requiring approval to open the change detail page.
3. In the Approval Workflow section, select Create Approval.
4. From the Approval Level dropdown, select your authority level (required).
5. From the Decision dropdown, select one: Approved, Rejected, or Conditionally Approved (required).
6. In the Comments field, enter any comments, conditions, or rationale for your decision (optional but strongly recommended for rejections and conditional approvals).
7. If your decision is Approved, select Get verification code. A six-digit code is emailed to you — enter it to electronically sign the approval (see Electronic signature below).
8. Select Submit Decision.

The page header displays the change number and title of the request being evaluated.

Approval levels

Level	Typical Authority
Initial	First-line review within the requesting area’s scope
Technical	Evaluates technical feasibility, implementation, and rollback
Management	Approves changes within the department’s or site’s authority
Quality Assurance	Reviews quality impact, compliance, and regulatory considerations

Note

Some change requests may require approval at multiple levels. For example, a process change affecting product quality may need approval at both the Management and Quality Assurance levels. The change transitions to Approved only once every recorded approval is decided and all are approved.

Electronic signature and segregation of duties

Approving a change is an electronic signature under 21 CFR Part 11:

• Verification required. An Approved decision requires a six-digit verification code sent to your email. The change is not approved until the code is confirmed — the approval decision, the signature, and the status change are recorded together as a single atomic action.
• Sign your own decision only. You can only sign the approval assigned to you. An administrator cannot approve on another user’s behalf.
• Segregation of duties. The person who requested a change can never approve it, even if they hold an approver role. A different qualified approver must sign.
• Rejections and conditional approvals do not require a verification code, but are still recorded with your identity and timestamp.

Decision options

Decision	Effect
Approved	The change is approved and can proceed to implementation
Rejected	The change is not approved. The request status moves to Rejected.
Conditionally Approved	The change is approved subject to conditions specified in the comments. Conditions must be addressed before implementation.

Caution

When selecting “Conditionally Approved,” always include the specific conditions in the Comments field. This ensures the change requestor and implementation team understand what must be addressed.

Status transitions

The approval decision directly affects the change request lifecycle:

Submitted / Under Review
        |
        +-- Approved -----------> Approved (ready for implementation)
        |
        +-- Rejected -----------> Rejected (change is not proceeding)
        |
        +-- Conditionally ------> Approved with conditions
            Approved               (conditions noted in comments)

After approval, the change proceeds through:

1. Implementation — The approved change is put into effect, tracked as a checklist of implementation tasks (see Implementation tasks and closure below).
2. Closure — Once every implementation task is complete, the change record is formally closed.

Implementation tasks and closure

Once a change reaches Approved, its detail page shows an Implementation & closure section. This is where the work the change actually requires gets tracked and, eventually, closed out.

1. Anyone who could edit the change request (the requester, or a holder of the change-control update/admin permission) can add an implementation task: a short description of a unit of work (e.g. “Update SOP-BR-001 to reference the new checkpoint”, “Train all shift operators on the revised procedure”).
2. As each task is finished, check it off. Completing a task records who completed it and when.
3. Once every task is checked off, a Close change button becomes available. Confirming it records the closure and moves the change to Closed — its final state.

A change cannot be closed with zero tasks, and cannot be closed while any task is still open — add at least one task, and complete every task, before closing. Once closed, the record (and its implementation tasks) become read-only, the same as an approved or rejected change request.

Note

There is no separate “Verification” status recorded on the change itself — verifying that an implementation task was done correctly is part of completing that task. The Verification method field captured in Impact assessment documents how verification should be performed.

After submitting a decision

After submitting your approval decision:

1. A success message confirms the decision was recorded.
2. You are automatically redirected to the change detail page.
3. The decision is recorded with your identity, timestamp, and comments.
4. The change request status updates based on the decision.
5. The requestor and relevant stakeholders can see the decision.

A decided change request cannot be edited

Approved and Rejected are the end of the change request’s life. Once a change request reaches either, its edit page no longer offers a form. Opening Edit shows a notice explaining that the record is closed, together with a link back to the change request.

To carry out further work on the same subject, raise a new change request rather than reopening a decided one. The decided record stays exactly as it was when the decision was signed — which is what makes it usable as evidence.

Caution

This is a change in behaviour. Approved and rejected change requests could previously be edited from this page. If your process relied on amending a change request after its decision, that work now belongs on a new change request that references the original.

Best practices

• Review all impact assessments before making a decision.
• Provide clear comments explaining the rationale for rejections.
• For conditional approvals, list specific and measurable conditions.
• Verify that the implementation plan and rollback plan are adequate before approving.
• Consider whether training requirements have been identified for the change.

Practical example: Multi-level approval for a document change

A pharmaceutical company is revising its batch record template (SOP-BR-001) to add an in-process control checkpoint for tablet weight verification. The change request CC-055 has completed impact assessment with a risk score of 4 (medium). Two approval levels are required.

Management approval

The production department manager reviews the change request and assessments. (They are not the person who requested CC-055 — the requester cannot approve their own change.)

1. They open CC-055 and select Create Approval in the Approval Workflow section.
2. They complete the form:
   • Approval Level: Management
   • Decision: Approved
   • Comments: “Reviewed technical assessment and implementation plan. The additional weight check at the 30-minute mark aligns with our process improvement goals from the annual product review (APR-2025-TAB). Production schedule impact is minimal — estimated 8 minutes additional time per batch. All 14 production operators will need training before go-live. Approved from a production operations perspective.”
3. They select Get verification code, enter the six-digit code emailed to them, then select Submit Decision.

Quality Assurance approval

The QA manager reviews the same request along with the Department Manager’s approval.

1. They open CC-055 and select Create Approval.
2. They complete the form:
   • Approval Level: Quality Assurance
   • Decision: Conditionally Approved
   • Comments: “The additional in-process control is appropriate and consistent with ICH Q7 Section 8.30 guidance. However, the following conditions must be met before implementation: (1) Update the sampling plan document SP-TAB-003 to include the new checkpoint data recording requirements. (2) Add the weight verification acceptance criteria (target +/- 5% of label claim) explicitly to the batch record template rather than referencing the specification document. (3) Complete OQ protocol for the revised batch record workflow in the electronic batch record system.”
3. They select Submit Decision. (A conditional approval does not require a verification code.)

The change requestor addresses each condition, updates the implementation plan, and the change proceeds to implementation once all conditions are satisfied.