Versioning

Minor versions while drafting, major versions at publication — every state preserved, every version recoverable.

Versioning is the mechanism that lets you answer, at any moment, the question "what did this document say on [date]?" Without a disciplined versioning policy, the answer is a reconstruction — piecing together email attachments, cached files, and people's memories. With one, the answer is a retrieval. docs365.ai builds on SharePoint's native versioning and adds the policy layer that turns raw version history into defensible document governance.

Stage 4 · Govern Business: Included Enterprise: Included Premium: Included Diamond: Included

✓

Illustration placeholder

At a glance

What you get

Four properties of this versioning model are what compliance customers call out as the reason they moved from a shared drive to a controlled DMS. Each one addresses a specific gap in how casual version control tends to fail.

Minor versions while drafting

Every save during drafting creates a minor version (1.1, 1.2, 1.3…); the full drafting arc is preserved.

Major versions at publication

Approval flow completion issues a major version (1.0 → 2.0); end-users only see majors in the public area.

Revertible to any prior state

Accidentally deleted a section two versions ago? Two clicks restore the document to any prior version.

Full history preserved

Every version — minor and major — is kept indefinitely unless the customer deliberately configures otherwise.

How it works

From first draft to full history

Versioning happens automatically as a byproduct of authoring and approving. Minor versions are created on every save during drafting; major versions are issued when an approval flow completes. No one has to "create a new version" — the product does it.

Drafting creates minor versions

Every save during authoring creates a new minor version — 1.1, 1.2, 1.3 — capturing the full drafting arc.

Approval issues a major version

When the sequential approval flow completes, the document transitions to the next major version (e.g. 1.x → 2.0).

End-users see only the current major

The public area shows the current approved major; superseded versions live in the archive, visible to editors.

Any version is revertible in two clicks

Context menu → Version history → select prior version → restore. The revert itself becomes a new version.

Before / after

What changes when this is on

The versioning failures that matter in regulated environments are specific and costly: lost prior states, ambiguity about which version was in force when, drafts being mistaken for published versions, accidental deletions with no recovery path. All of them become structurally impossible.

Without it

With intranet.ai

✗ "What did this SOP say on March 14?" — reconstructed from whatever files people kept

✓ Open the audit log, find the version active on March 14, retrieve it. Not a reconstruction — the actual document

✗ End-users accidentally reading a draft (minor version) instead of the approved (major) version

✓ End-users only ever see majors in the public area; minors are invisible to them

✗ Accidental deletion of a section that was critical — gone forever

✓ Revert to any prior version in two clicks; the deletion itself becomes a documented event

✗ Unclear policy about when versions get pruned; old history disappears before anyone notices

✓ No automatic pruning; versions are kept indefinitely unless the customer deliberately configures retention

Availability

Plan availability

Versioning is a core feature on every DMS plan — SharePoint's native version history is the underlying mechanism, and the product inherits it on all tiers. What varies across plans is the support model for version policy configuration, not the capability itself.

business

enterprise

premium

diamond

✓ Included

Versioning is included on every DMS plan using SharePoint's native version history. Version-policy design (when majors vs minors; retention rules) is part of Enterprise and above onboarding.

Keep exploring

Related features

Versioning connects to the audit log (which events refer to versions), to sequential approval (which issues major versions), and to archiving (where superseded versions go). These three features define the version lifecycle.

Stage 4 · Govern

Audit log

Every action, every approval, every version — captured against a named user, accessible in 30 seconds.

Stage 4 · Govern

Archiving

Superseded and retired documents leave the active view but stay part of the permanent record — retrievable for every future audit.

Stage 2 · Approve

Sequential approval

Named approvers, in defined order, with role-based routing — every step logged, every version tied to the approvals that produced it.

Deep dive

Read the full narrative

For the buyer who wants the full detail — compliance context, edge cases, adjacent workflows.

Minor versions while drafting. Major versions at publication. Full history, always.

Versioning is the mechanism that lets you answer, at any moment, the question “what did this document say on [date]?” Without a disciplined versioning policy, the answer is a reconstruction. With one, the answer is a retrieval.

Minor versions and major versions

Minor versions (0.1, 0.2, 0.3, 1.1, 1.2, 2.1, etc.) are the drafting states. Every time an editor saves the document during authoring, a new minor version is created. Minor versions capture the evolution of a draft — who changed what, when, with what comments.

Major versions (1.0, 2.0, 3.0, etc.) are the published states. A major version is issued when a document completes its approval flow and moves to the public area. Major versions are what end-users see; they’re also the canonical reference points in the audit log.

The distinction matters operationally. Between 1.0 (currently published) and 2.0 (the next published version), there can be many minor versions — 1.1, 1.2, 1.3, and so on — that capture drafting progress. When 2.0 is approved and published, all the minor versions between are still preserved in the history; they just aren’t visible in the active public area.

Preserved, always

Every minor version is preserved. Every major version is preserved. SharePoint’s native versioning handles this at the platform layer; we use it directly. There’s no retention policy that automatically discards old versions — they’re kept indefinitely unless the customer deliberately configures otherwise.

Revertible to any prior state

If a colleague accidentally deletes a section — or an intentional change later proves wrong — the document can be reverted to any prior version in a couple of clicks. Version history is visible via the document’s context menu; reverting restores the document’s content to the state of the selected prior version. The revert is itself a new version in the history.

The audit question: “what did this document say on [date]?”

The practical use case that makes versioning valuable: an auditor, a lawyer, a compliance officer asks for the exact state of a specific document on a specific historical date. With versioning plus the audit log:

Look at the audit log for the document.
Find the version that was published / active on the asked-about date.
Retrieve that version.

Not a reconstruction. The actual document as it existed. For ISO 9001 surveillance, for 21 CFR Part 11 inspections, for litigation holds, for FOI requests — this retrieval capability is the evidence that the document-management system is actually governing the document’s history.

Versioning policy — a customer decision

What counts as a major vs. minor version is often a policy question, not a pure system question. Common patterns:

Major = published. The default. Major versions are what the approval flow produces; minor versions are drafting states.
Major = material change. Some customers use major versions only for substantive policy changes, with minor versions for typographic or clarifying updates even if published. The product accommodates either pattern.

Tier A compliance (ISO 9001 + ISO 27001 + GDPR) expects some consistent versioning policy, but doesn’t prescribe which. Tier B compliance (HIPAA, FDA 21 CFR Part 11, SOX) has similar expectations — the policy must be documented, not what it must say. Customers define their own; the product enforces it.

What the public area shows

End-users see only the latest major version in the public area. They never see minor versions (drafts). They don’t accidentally act on a superseded version because they can’t see superseded versions; those are in the archive, visible to editors and compliance.

Audit log — every version event is captured in the log.
Sequential approval — the event that issues major versions.
Archiving — how superseded major versions leave the active view.
Document versioning for regulated industries — the deep dive on versioning as a policy.

Lifecycle stage: Govern →

Deep dive · Pillar guide

The active document lifecycle on SharePoint Online

Why passive document management fails — and what an explicit four-stage lifecycle looks like in practice inside a Microsoft 365 tenant.

22 min read · 5,200 words

Read the full guide

See this feature running on your documents

Thirty minutes. No cost. No obligation. We'll walk through how versioning fits into your current document-governance practice.

Book a free assessment or see all features