Document Statuses and Lifecycle

Document status is the current workflow state of a document or version. A document lifecycle is the controlled sequence of states and transitions that governs creation, editing, review, approval, publication, revision, retirement, and archival.

A practical baseline is:

Draft → In Review → Approved → Published → Archived

Rejected work returns to Draft. A published document must become a new draft before it can be changed. Keep status separate from version and revision numbers: status answers what may happen now, while version history records which saved iteration changed.

What are the stages of a document lifecycle?

Status	Purpose	Typical permissions	Next states
Draft	Content is being created or edited.	Owner and editors can change it; readers do not see it as final.	Ready for review, archived, or deleted.
Submitted / Ready for review	The owner has requested review and the item is queued.	Owner may be limited to metadata or withdrawal.	In review or returned.
In review	Reviewers and approvers evaluate a specific version.	Editing may be locked or restricted.	Changes required or approved.
Changes required / Returned	A reviewer rejected the submission or requested corrections.	Owner and editors can revise it.	Draft or resubmitted review.
Approved / Ready for publishing	All required decisions are complete.	Usually read-only; only a publisher can release it.	Published, scheduled, or sent back if policy changes.
Published	The approved version is visible to its intended audience.	Readers can access it; edits create a new version.	Superseded, unpublished, or archived.
Superseded	A newer published version replaced this one.	Read-only; retained for history.	Archived or restored according to policy.
Archived	The document is retained for records but removed from active use.	Records managers or administrators only.	Restored or permanently disposed of under retention rules.

These names are implementation choices, not a universal standard. Autodesk documents a workflow that moves documents through statuses to publication; SharePoint distinguishes draft minor versions from published major versions; Adobe Experience Manager Guides provides configurable states such as Draft, In Review, and Reviewed; and ServiceNow examples include Returned and Ready for Publishing stages. See the relevant product documentation from Autodesk, Microsoft, Adobe, and ServiceNow.

How status differs from version and revision

Do not put all three concepts in one field:

Concept	Question it answers	Example
Status	What can happen to the item now?	In review
Version	Which saved iteration is this?	v17
Revision	Which released change level is this?	Rev C
Publication	When and where was it made available?	Published to the customer portal on 2026-09-30

A reviewer should approve an exact version, not “whatever is current.” If an editor changes the file after approval, either invalidate the approval or create a new version whose status is Draft. Autodesk describes check-in/check-out as a way to record versions and increment revision at publication. SharePoint uses major and minor versions to distinguish published content from drafts, while Adobe can make an approved document read-only and create a new version for later edits.

A transition model that is easy to audit

Write legal transitions down before implementing them. For every transition define the actor, required evidence, side effects, and failure path.

From	Action	To	Who	Required evidence
Draft	Submit	Ready for review	Owner	Required fields complete
Ready for review	Start review	In review	Reviewer	Reviewer assigned
In review	Request changes	Changes required	Reviewer	Comment and reason
Changes required	Revise	Draft	Owner	New version created
In review	Approve	Approved	Required approver(s)	Decision, identity, timestamp, version
Approved	Publish	Published	Publisher or automation	All approvals satisfied
Published	Edit	Draft	Authorized editor	New version linked to prior publication
Published	Retire	Archived	Records owner	Retention or retirement reason

Keep an append-only transition log. Each record should contain the document ID, from-state, to-state, actor, timestamp, version reviewed, decision comment, and correlation ID for automated jobs.

Reference data model

CREATE TABLE documents (
  id UUID PRIMARY KEY,
  title TEXT NOT NULL,
  status TEXT NOT NULL CHECK (status IN (
    'draft', 'ready_for_review', 'in_review', 'changes_required',
    'approved', 'published', 'superseded', 'archived'
  )),
  current_version_id UUID,
  published_version_id UUID,
  published_at TIMESTAMP WITH TIME ZONE,
  archived_at TIMESTAMP WITH TIME ZONE,
  updated_at TIMESTAMP WITH TIME ZONE NOT NULL
);

CREATE TABLE document_versions (
  id UUID PRIMARY KEY,
  document_id UUID NOT NULL REFERENCES documents(id),
  version_number INTEGER NOT NULL,
  revision TEXT,
  content_hash TEXT NOT NULL,
  created_by UUID NOT NULL,
  created_at TIMESTAMP WITH TIME ZONE NOT NULL,
  UNIQUE (document_id, version_number)
);

CREATE TABLE document_transitions (
  id UUID PRIMARY KEY,
  document_id UUID NOT NULL REFERENCES documents(id),
  from_status TEXT,
  to_status TEXT NOT NULL,
  version_id UUID,
  actor_id UUID NOT NULL,
  comment TEXT,
  created_at TIMESTAMP WITH TIME ZONE NOT NULL
);

Use a transaction and an optimistic-lock field when changing status. The update should fail if another editor changed the document since it was read.

UPDATE documents
SET status = 'approved', updated_at = CURRENT_TIMESTAMP
WHERE id = :document_id
  AND status = 'in_review'
  AND current_version_id = :reviewed_version_id
  AND updated_at = :expected_updated_at;

Approval rules and visibility

• Record the exact version and content hash each approver saw.
• Require comments for rejection and changes-required decisions.
• Choose whether approvals are sequential, parallel, quorum-based, or single-approver.
• Prevent publication until every required gate succeeds.
• Decide whether readers can see pending drafts. SharePoint’s Pending status can hide a draft from readers until approval.
• Decide whether editing during review is blocked, creates a new version, or restarts review.
• Make approved and published versions read-only; create a new draft for edits.
• Preserve superseded and archived versions for the period required by your retention policy.

Implementing the workflow

1. Define the vocabulary

Start with the smallest set that reflects real decisions. Map product-specific labels such as “Reviewed,” “Pending,” or “Ready for Publishing” to your canonical states.

2. Define legal transitions

Represent transitions as data or a state-machine library instead of scattering status checks through controllers.

const transitions = {
  draft: { submit: 'ready_for_review' },
  ready_for_review: { start_review: 'in_review', withdraw: 'draft' },
  in_review: { approve: 'approved', request_changes: 'changes_required' },
  changes_required: { revise: 'draft' },
  approved: { publish: 'published', cancel: 'draft' },
  published: { edit: 'draft', retire: 'archived' },
  archived: { restore: 'draft' }
};

function transition(document, action) {
  const next = transitions[document.status]?.[action];
  if (!next) throw new Error(`Illegal transition: ${document.status} + ${action}`);
  return { ...document, status: next };
}

3. Bind roles to actions

For example, an author may submit and revise, a reviewer may request changes, an approver may approve, and a publisher may publish. Check both role and version before applying the transition.

4. Emit audit events

Write the transition and its evidence in the same transaction as the status update. Send notifications after commit so a failed email does not leave a half-completed workflow.

5. Test failure paths

• Two users approve different versions.
• An approval arrives after the document was withdrawn.
• A required approver is unavailable.
• A publish job is retried after a timeout.
• A new edit arrives while the old version is in review.
• A document is unpublished and then restored.

Edge cases to handle explicitly

Concurrent editing

Use optimistic locking or check-out. Never silently attach an approval to a version different from the one the approver reviewed.

Scheduled publication

Store the scheduled time and timezone separately from approval time. At execution, verify that the approved version is still current; otherwise cancel or require reapproval.

Unpublishing

Define whether unpublishing restores the previous published version, shows no version, or creates an unpublished state. Keep the event in the audit log.

Localization

Track approval per locale when translations can change independently. A translated version should not inherit approval from the source unless policy explicitly allows it.

Automation and retries

Give each transition request an idempotency key. A retry must return the original result rather than publish twice or append duplicate audit events.

Deletion and retention

Separate logical retirement from physical deletion. Legal holds and retention schedules can prevent deletion even after a document is archived.

Common errors and fixes

Symptom	Cause	Fix
A published document is edited in place.	Status and content are stored together without versioning.	Create a new version and move it to Draft.
Readers see unapproved text.	Visibility is based on the current version instead of the published version.	Serve only published_version_id to readers.
An approval applies to the wrong content.	The workflow did not pin the approved version.	Store and verify the version ID and content hash.
Rejected items cannot be resubmitted.	There is no legal transition from Returned to Draft.	Add a revise transition that creates a new version.
Duplicate notifications or publications occur.	Workers retry non-idempotent commands.	Use idempotency keys and transactional outbox events.
Status history is incomplete.	Only the current status is stored.	Use an append-only transition table.
Different teams use incompatible names.	Status labels were not mapped to a canonical vocabulary.	Define canonical states and display labels separately.

Performance, reliability, and cost

• Performance: Index (document_id, created_at) on versions and transitions, and index status for queue workers. Keep large binaries outside the relational row while storing immutable hashes and metadata in the database.
• Reliability: Use transactional state changes, an outbox for notifications, idempotent workers, and reconciliation jobs for scheduled publishing.
• Consistency: Prefer one authoritative publication pointer. Caches should be invalidated only after the database commit.
• Cost: Archive cold versions to lower-cost storage, but retain searchable metadata and hashes. Avoid repeated full-text reprocessing when only metadata changes.
• Operations: Monitor time spent in each state, rejected submissions, overdue approvals, publish failures, and documents with no active owner.

Or skip the browser setup

If your workflow needs preview images of approved documents or web pages, ScreenshotNeo can capture the result with one request. It removes cookie banners, newsletter popups, and chat widgets before the shot; bot checks, blank pages, timeouts, failed loads, and cache hits are not billed; and response headers identify the page verdict and whether the capture was billed. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. Read the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo supports full-page and element captures, device presets, retina scale, custom CSS and JavaScript, waits, request blocking, headers, cookies, user agents, geolocation, PDF output, caching, signed links, async jobs, bulk capture, and a usage API. It is a website screenshot API and MCP server with 1,000 free screenshots each month without a card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

FAQ

What is the minimum useful lifecycle?

For a small team, Draft, In review, Approved, Published, and Archived are usually enough. Add Returned when reviewers need a distinct correction path.

Should every save create a version?

Create versions at meaningful checkpoints or check-ins. Always create a new version when content changes after approval or publication.

Can status and version be one field?

No. A status is a workflow state; a version is a historical iteration. Combining them makes visibility, approvals, and rollback error-prone.

Who should be allowed to publish?

Use a dedicated publisher role or controlled automation. Publication should verify that all required approvals apply to the exact version being released.

When should a document be archived?

Archive it when it is no longer active but must be retained. Apply retention, legal hold, and disposal rules separately from the workflow status.

Implementation checklist

• Define canonical statuses and display labels.
• Store status, version, revision, publication date, and prior-publication state separately.
• Document every legal transition, actor, permission, and failure path.
• Pin each approval to a version and content hash.
• Make visibility rules explicit for drafts, pending items, published versions, and archives.
• Record timestamps, identities, comments, and transition history.
• Test rejection, resubmission, concurrent edits, supersession, unpublish, scheduling, and retention.

For a standards-oriented design, GOV.UK’s technical guidance is a useful example of explicit states and legal actions, while Autodesk, SharePoint, Adobe Experience Manager Guides, and ServiceNow show how production systems implement review, approval, publication, versioning, and archival controls.