Documents

Every SOP, controlled and current.

Manage SOPs, policies and quality records with version history, signed approvals and a hash-verifiable snapshot of every effective version — so the document your team uses is always the one in force.

Book a demo See pricing

A controlled SOP open in QAbility at effective version 1.0, its approval route complete from submission through technical review and approval to effective, with the document's properties beside it.

The version lifecycle

A version can only move where the database lets it

Every controlled document version walks the same graph. The moves below are the database’s own list — not a convention the interface follows.

7 states

Draft: Authored and edited. The only state a version can be created in.
In review: Routed through its approval workflow, step by step.
Approved: Signed off, waiting for its scheduled effective date.
Effective: In force. At most one per document.
Superseded: A newer version took effect. Kept on record, never deleted.
Changes requested: Sent back for edits. In the graph, not offered in the app today.
Rejected: Turned down. The author fixes it in place and resubmits.

11 legal moves

Move 1: Draftto In review
The author submits it for review.
Move 2: In reviewto Draft
The author cancels the review and takes it back.
Move 3: In reviewto Approved
The last approval step completes; the version waits for its effective date.
Move 4: Approvedto Effective
Its effective date arrives and a scheduled job re-checks and releases it — or an approver sets it effective.
Move 5: In reviewto Effective
Auto-effective: the last approval releases it at once. Refused unless its approval workflow has completed.
Move 6: Effectiveto Superseded
A newer version takes effect; the database demotes this one in the same write.
Move 7: In reviewto Rejected
A reviewer rejects it, with a comment.
Move 8: Rejectedto In review
The author fixes it and resubmits.
Move 9: In reviewto Changes requestedNot offered in the app today
A reviewer requests changes.
Move 10: Changes requestedto In reviewNot offered in the app today
The author resubmits.
Move 11: Changes requestedto DraftNot offered in the app today
The author pulls it back to editing.

Eleven moves are legal, and the database refuses every other one. It also refuses any status change that doesn’t come from the server: a version is created as a draft and moves only through review, approval and its effective date.

Moves 9 to 11 are in the database’s graph, but the approval screen doesn’t offer “request changes” today. A reviewer who wants edits rejects the version, and the author fixes and resubmits it (moves 7 and 8).

In force on any date, one version at a time

Each version holds the slot until the next one takes effect. Ask which SOP was in force on a given day and there is exactly one answer — with the PDF that was filed the day it took effect.

v1.0 Superseded
In force until 2.0 took effect
Its PDF snapshot and hash stay on record.
v2.0 Superseded
In force until 3.0 took effect
Its PDF snapshot and hash stay on record.
v3.0 Effective
In force since 27 Apr 2026
PDF snapshot filed and hashed when it took effect.
v4.0 Draft
Not in force — being written
No snapshot until it takes effect.

Demo data: SOP-QA-014 Deviation Management in the Nordvale Biotech Labs demo company, whose printed 3.0 is shown further down. Earlier effective dates are left out.

The moment a version takes effect

The previous version is superseded
In the same database write. A unique index backs it up, so two versions of one document can never both be effective.
A PDF snapshot is filed and hashed
The cover and sections are rendered to PDF with attachments merged in, and its SHA-256 hash is recorded on the version. The hash can be re-checked against the stored file on demand.
Training goes out on that version
Where training is set up for the version, the roles and people it names are assigned it, pinned to the version that just took effect.

Electronic approvals

Every approval, signed by the person who gave it.

Route a version through your review workflow: steps in order, reviewers chosen by role or by name, and an all-or-any rule on each step. On steps that require a signature, the approver re-enters a dedicated signature PIN at the moment of signing, and the signature records who signed, what it means and when.

Sequential steps with all-or-any approval
Re-authentication at signing
An approval already in flight keeps the rules it started under

A draft SOP being submitted for review: its approval steps in order — technical review, then approval — each with the reviewers picked for it and whether all or any of them must approve.

Controlled copies

Every printed copy says which version it is.

The controlled print view puts the document number, version, status and effective date at the top of the copy. Behind it, the hashed PDF filed on the effective date is the record of exactly what was in force.

Schedule a future effective date, or release on approval
Every revision records its reason, type and impact
Periodic review as a signed decision: no change, revise or retire

The controlled print view of an effective SOP: company header, EFFECTIVE status, a document block with number, version and effective date, and the numbered sections below.

What the system enforces

The rules behind a controlled document

Each rule says where it lives — so you know which ones a misconfiguration can’t switch off.

Created as a draft, moved only by the server: A version can only be created as a draft, and its status can’t be changed by a direct data edit — only by submit, the approval workflow or its effective date.; Database refuses
One effective version per document: The outgoing version is superseded in the same write, and a unique index refuses a second effective version even if two releases race.; Database refuses
Auto-effective needs a completed approval: A version can’t jump from In review to Effective unless its approval workflow has actually completed.; Database refuses
Approved and effective versions can’t be deleted: Only a draft or a rejected version can be deleted. A version that was approved or in force is part of the record; the document is made obsolete instead.; Database refuses
A snapshot’s hash can be re-checked: On request, the stored PDF is read back, hashed again and compared with the hash recorded when it was filed.; Server refuses
Signatures where your workflow asks for them: You decide which approval steps require an electronic signature, and whether all or any of the reviewers must approve.; You configure

Connected records

Where a document sits in your quality system

The links QAbility keeps, visible from both records.

Comes from — Document

A new version starts from the document itself. A change request or CAPA that prompted it can be linked to it as related.

Leads to — Document

TrainingAssigned
When a version takes effect, the people it names are assigned training on that exact version — where training is set up for the document.

Any NC, CAPA, change request, internal complaint, quality event, inspection lot, document or custom-module record can also be linked by hand as related.

Document control questions

Straight answers

Can a document be approved without an electronic signature?

Yes, if you allow it. Signatures are set per workflow step: steps marked as requiring one ask the approver to re-authenticate, and other steps record the approval as a completed task.

What happens to the old version when a new one takes effect?

It becomes Superseded. It stays on record with its approvals and snapshot, so you can show exactly which version was in force on any date. Only one version of a document can be effective at a time.

Does QAbility escalate a review that runs late?

Not automatically. Each review and approval step gets a due date from the workflow, and overdue tasks show in the assignee’s queue, but nothing escalates or reassigns them on its own today.

See a controlled document go from draft to effective.

Book a demo See pricing