Approval Workflow: Controlled Reviews and Approvals

What an approval applies to

The central question is not simply “Is the batch released?” but: What use was authorized, by whom, and on the basis of which version reviewed? A documentation review, a material release, and an acknowledgment may concern the same subject yet have different effects.

The decision needs an unambiguous subject of review

Before approval, it must be clear what is being decided on. This may be a document, batch documentation, a test result, a deviation assessment, an SOP version, or a material movement. The subject of review needs a unique identity and a specific version.

If relevant data change after the review begins, the earlier decision must not silently be transferred to the new version. Depending on the substantive significance, the approval becomes invalid, another review is required, or the change is treated as a controlled addition.

An approval workflow should therefore store more than an object ID. It must also reference the version assessed: for example, a document version, hash value, change number, or uniquely identified dataset. Only then can it remain clear which content the decision-maker actually had available.

Version 2 is returned; version 3 is approved

This illustrative example concerns the internal approval of batch documentation. It does not represent complete batch certification under pharmaceutical law. Version 2 contains a measurement correction without sufficient justification. The reviewer returns that specific version, identifying the deficiency.

In an Electronic Batch Record, that approval is part of the complete batch-specific record. The approval workflow controls the associated decision process; it does not replace the rest of the batch record.

The addition produces version 3. It contains the justification and the reference to the earlier correction. The resubmission shows both the change and the reason for return. The review checks whether the deficiency has been resolved and whether other content is affected, using the criteria established for this example.

The subsequent approval applies to version 3 with the explicitly stated meaning. It does not retroactively turn version 2 into an approved submission. Nor does approval of the documentation grant any additional permission to use the material if a separate decision is required for that purpose.

Workflow models specify which review stages the resubmission must pass through again. The documented individual case then shows which of these reviews actually took place. When selecting compliance software, the demonstration should therefore show separately which version of the documentation was approved and which material use the decision actually permits.

Rework extends the history rather than replacing the earlier review

When an item is returned for rework, the reason, affected points, and expected correction must be identifiable. The person handling it receives a new task without the original submission and return disappearing.

After correction, the entire approval flow does not necessarily restart. The model can specify whether only changed parts, all review criteria, or an additional stage must be assessed again. This decision depends on risk and the substantive context.

A good return loop does more than impose technical limits on repetition. It shows why an item was returned several times and whether recurring errors indicate unclear requirements, missing information, or unsuitable task guidance.

Approval, rejection, and rework are different states

A simple approval flow often starts with “draft” and proceeds through “for review” to “approved.” This linear sequence is rarely sufficient for real processes. The item may be incomplete, prompt questions, be rejected or withdrawn, or be replaced by a new version.

Each outcome needs an unambiguous effect. “For rework” is not the same as “rejected.” Rework permits a controlled return followed by re-entry into review. Rejection may end the process or require a new submission. “Approved with conditions” should be used only when its meaning, deadline, and subsequent process are clearly modeled.

BPMN 2.0.2 provides activities, user tasks, events, and gateways for formally describing such decision paths.^[1] However, the notation does not automatically provide states that are correct in substance. These must be derived from the actual decision process.

A decision needs context and meaning

The decision-maker must see the information relevant to the task: the subject of review, version, open deviations, previous returns, measurement results, applicable requirements, and, where relevant, the consequences of the decision.

Too much unstructured information can impair a review just as missing data can. For Human in the Loop to enable effective review, the workflow must provide the necessary context selectively and make missing information visible.

The meaning must be unambiguous at completion. “Reviewed,” “approved,” “released,” “acknowledged,” and “responsibility accepted” are not interchangeable terms. They may have different substantive or legal effects.

For GxP data, the MHRA makes the review itself more explicit: it should be risk-based and documented, and the review record should state whether issues were found, when the review was performed, and who confirmed it. Where an electronic signature is used, its visible manifestation should also identify the person, role or title, the date and, where significant, the time, as well as the meaning of the signature. ^[6] A technical confirmation is therefore meaningful only when it points to a specific review and a specific decision meaning.

Check authority and independence for this approval

Decision-making authority must relate to the subject of review and the specific approval step. A person may be authorized to review documentation without being allowed to authorize subsequent material use. A substitute must cover the same required scope of responsibility.

WS-HumanTask distinguishes, among other things, potential and actual owners and describes the transfer of human tasks.^[2] The specific approval process must additionally establish whether the person taking over is sufficiently qualified and independent.

Where separation of duty is required, earlier involvement in the process also matters. Two role names alone do not demonstrate that two independent people performed the reviews.

Multistage approvals need a defined sequence

A four-eyes principle can be implemented as parallel or sequential review. In sequential approval, a function responsible for the subject matter decides first, followed by a quality assurance role. In parallel review, two independent decisions are obtained.

The model must clarify whether both approvals are required, whether a rejection ends the process immediately, and whether an earlier approval remains valid after a change. Equally important is whether the same person may perform multiple stages.

For critical steps in paper-based batch records, PIC/S describes a staged review in the GMP/GDP context: review or witnessing by independent and designated personnel at the time of the operation, review by an approved person in production, and review and approval by the Quality Unit before release or distribution of the batch. ^[7] This is not a general four-eyes rule for every approval; it shows that review roles and sequence have to be derived from the substantive criticality of the particular process.

Simply having two signatures is not enough. What matters is the distinct contribution of each responsibility. A technical identity check does not automatically prevent the same person from exercising two organizationally separate roles. The approval workflow must enforce the specific separation of duty.

The process also needs a defined resolution for conflicting outcomes. If one person approves and another rejects, the system must not silently adopt whichever decision was submitted last. Options include a joint clarification task, resubmission after correction, or escalation to a role authorized for that purpose. The conflict and its resolution remain separate events in the record.

Changes after approval need a new controlled process

A completed approval must not remain in effect simply because the approved content is subsequently overwritten. Substantial changes produce a new version and a new review or approval process.

The previous version is retained with its decision. The new version can reference it, identify changes, and explain why another review is necessary. Minor metadata corrections may be handled more narrowly but still need a traceable rule.

An audit trail documents relevant changes and interventions. The approval workflow adds their substantive process effect to this history: which version was submitted, returned, approved, or replaced.

Withdrawal and revocation need a visible consequence

New information may emerge after approval: a corrected test result, an identified deviation, or a revised assessment. It must then be defined whether the approval is withdrawn, the item is placed on hold, or an additional investigation process begins.

The earlier approval remains a historical fact. It is not deleted but supplemented by a later, justified status. At the same time, users must be able to see immediately that the earlier approval no longer governs their actions.

Dependent processes must also be considered. If material has already been reserved or a batch has undergone further processing, revocation may trigger follow-up tasks in other process instances. The approval workflow needs clear relationships to the affected objects for this purpose.

A pending decision remains pending

A reminder or escalation can help move an open approval forward organizationally. It does not, however, provide consent where an active decision is required. Until then, use of the item remains subject to its previously permitted state.

If responsibility changes, the new person must receive the same submission with the open review points. A workflow engine can coordinate waiting and routing; this does not replace a substantive assessment.

Approval status and electronic signature are not identical

A system can set a status to “approved” without this automatically constituting an electronic signature in the regulatory sense. Conversely, a signature can have different meanings, such as review, approval, responsibility, or authorship.

For electronic records within its scope, 21 CFR Part 11 requires, among other things, controlled system access, time-stamped audit trails, operational checks, and authority checks. For signed electronic records, the signature manifestation must identify the name, date and time, and meaning of the signature; the signature must be linked to its associated record.^[3]

These requirements do not apply indiscriminately to every approval workflow. First, the regulatory and substantive rules applying to the specific dataset and market must be determined. In its guidance on the scope of Part 11, the FDA also explains the connection to the applicable underlying recordkeeping requirements.^[4]

A signature does not replace a substantive review. Identity and the meaning of responsibility must be connected to an actual review.

Distinguish approvals in the GMP environment

EU-GMP Annex 11 addresses computerized systems in the GMP environment. The controls it covers include access rights, audit trails considered on a risk basis, and periodic evaluation of systems. Electronic signatures should be permanently linked to their respective records and include the date and time.^[5]

Section 15 contains additional specific requirements for batch certification and release recorded using computerized systems: certification is reserved for Qualified Persons; the person releasing or certifying the batch should be clearly identified and recorded using an electronic signature. General internal approval of documentation must be distinguished from this.

An approval workflow replaces neither this substantive responsibility nor validation of the system for its intended purpose. What matters is which specific approval is represented and which requirements apply to it.

An approval can only be understood together with its subject

The return of version 2 and the approval of version 3 can both be correctly documented. What matters is that the interface shows the valid decision for today's work and that the history can explain how it came about.

Anyone tracing an approval later must therefore consider the reviewed content, the meaning of the decision, and subsequent changes together. Only this connection turns the word “approved” into a usable statement.

An approval does not prove that all source data are correct. The quality of the decision depends on the version reviewed. An audit trail does not replace an approval workflow. Change history and substantive decision logic serve different purposes.