PDF publication

Word becomes immutable PDF the moment approval completes — automatically, without a human deciding.

The gap between "approved" and "published" is where most document-control programs leak integrity. Someone has to remember to export the Word file to PDF. Someone has to upload it to the right folder. Someone has to notify the team. Each of those manual steps is a place where version drift starts and evidence gets lost. docs365.ai closes the gap by making publication automatic — the moment the final approver signs off, the Word document is converted to PDF, the PDF lands in the public area, and the version becomes immutable.

Stage 3 · Publish Business: Included Enterprise: Included Premium: Included Diamond: Included

✓

Illustration placeholder

At a glance

What you get

Automatic publication is more than a convenience. Four specific behaviors turn it into a compliance capability — each one removing an opportunity for the approved version and the published version to diverge.

Word → PDF automatic conversion

The moment approval completes, the Word document is rendered to PDF using native Microsoft 365 conversion.

Immutable published version

The PDF is what end-users see — read-only, unmodifiable, the single source of truth for the approved content.

Metadata preserved in conversion

Cover page, protocol code, version number, approver names, effective date — all carried intact into the PDF.

Zero manual steps

No export, no upload, no notification — the final approval is the publish event, one atomic transition.

How it works

From approval to immutable PDF

Publication is triggered by the completion of the sequential approval flow. There is no separate "publish" action — the final approver's signature is the publish event. The system converts, moves, notifies, and logs as a single atomic transition.

Final approver signs off

The last step of the sequential flow completes; the document is now officially approved at a new major version.

System converts Word to PDF

Native Microsoft 365 rendering produces the PDF inside the tenant — no external service, no data leaving the tenant.

PDF moves to the public area

The published PDF lands in the public library; end-users can now see it; the Word source stays in the editing area.

Distribution email sends (if configured)

If the document type has a distribution list configured, the publication email goes out in the same transaction.

Before / after

What changes when this is on

The failure modes that PDF publication prevents are specific and expensive: the approved-but-never-published document, the Word version that was distributed instead of the PDF, the end-user who edited a "published" Word file. Each one becomes structurally impossible.

Without it

With intranet.ai

✗ Approved document sits in limbo because no one remembers to export it to PDF

✓ The final approval IS the publication; there is no limbo state

✗ End-users read the Word file (editable, unsigned) instead of the approved PDF

✓ Word source stays in the editing area; the public area only ever contains the PDF

✗ Metadata drift between Word master and PDF distribution — different cover pages, different versions

✓ The PDF is generated from the Word master in one transaction; drift is impossible

✗ "Was this published from the approved version or a draft?" — unanswerable without the audit log

✓ The PDF carries the version number and approval evidence inline — answerable from the document itself

Availability

Plan availability

Automatic PDF publication is a core lifecycle feature and is included on every DMS plan. The conversion runs inside the Microsoft 365 tenant using native Word-to-PDF rendering; no third-party converter, no external service, no extra subscription.

business

enterprise

premium

diamond

✓ Included

Automatic Word-to-PDF publication is included on every DMS plan. Conversion for PowerPoint, Excel, and other formats is also supported — Word is privileged because the compliance use case benefits most from immutable output.

Keep exploring

Related features

PDF publication is the transition between approval and distribution. These three features produce the events that lead into it and the notifications that follow it.

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.

Stage 3 · Publish

Distribution-list notification

The right people learn about the document the moment it's published — automatically, with the link to the approved PDF.

Stage 2 · Approve

DocuSign e-signature integration

PAdES signatures — simple and advanced — cryptographically bound to the approved PDF, inside the same approval flow.

Deep dive

Read the full narrative

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

When a document is approved, the Word original becomes a published PDF in the public area — automatically.

Publication is the stage where “being worked on” becomes “in effect.” It’s also the stage where most DMS implementations stumble: the approved document sits somewhere that isn’t obvious to end-users, old versions stay visible alongside new ones, and people end up acting on editions the author thought they’d retired. This product handles publication as a one-way automatic step, triggered by approval completion.

What happens the moment the last approver signs off

Three things happen automatically, in order:

The Word document is converted to PDF. The PDF is the canonical published format — auditors reference it, end-users download it, it travels cleanly through email and systems. Word’s editable nature makes it the wrong format to publish; PDF is the right one.
The PDF is moved to the public area. The library has two zones — the editing area where drafts and approvals happen, and the public area where end-users see published documents. Publication = move from one zone to the other.
Metadata is updated. Publication date is stamped. The approved version number becomes the version end-users see. Status flips from “in approval” to “published.”

Nobody has to export anything, copy anything, upload anything, or notify anybody manually. Approval completes, publication happens.

The public area end users see

End-users who consume policies — the workforce, not the authors — land on the public area of the relevant library. They see a clean list of document types (SOPs, work instructions, policies, whatever the department publishes) and the current approved PDF for each. Each document shows:

Title and protocol code.
Status (Published / Archived).
Publication date.
Filterable metadata — language, applicable facility, document category, whatever the customer configured.

They click the document. They see the PDF. They get the current, canonical version. No guessing, no stale copies, no “is this the latest?”

Word-to-PDF is the automatic path

Word documents specifically are converted to PDF at publication. The Word source remains in the editing area for the next revision; the PDF is what end-users see.

Other formats publish in their original form

PowerPoint, Excel, and PDF source files are supported as document types but are published in their original format — not converted to PDF. This is a deliberate design choice:

A PDF of a PowerPoint slide deck is of limited value — recipients often need to edit or reuse slides.
A PDF of an Excel spreadsheet can’t be filtered or sorted — recipients need the live file.
A PDF that’s already a PDF doesn’t need re-conversion.

So the published artifact matches how the recipient is expected to use it: PDF for static reference documents, native format for working artifacts.

The canonical-version property

Once published, the PDF is the single source of truth. Older versions aren’t visible in the public area; archived versions are retrievable only through the archive view (visible to editors and compliance). This is the property that makes “which version is in effect?” trivially answerable — the public area shows exactly one version per document.

What happens when a new version is published

The revision cycle looks like this:

Editor opens the approved document in the editing area (the Word source).
Creates a minor revision (e.g., 1.0 → 1.1) and drafts changes.
Launches a new approval flow when ready.
On approval completion, the new version (e.g., 2.0) is published to the public area.
The previous published version (1.0) moves to archive — still retrievable, but no longer visible as the active version.

End-users see only the new 2.0. Editors and compliance still see 1.0 in the archive when needed.

Distribution-list notification — how publication reaches the right people.
Read-receipts — for documents that require acknowledgment.
File format support — which formats are handled how.
Archiving — what happens to the prior version at publication.

Lifecycle stage: Publish →

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 pdf publication fits into your current document-governance practice.

Book a free assessment or see all features