How can Confluence Version History support a formal review and sign-off process?

Question

We use a live Confluence document to manage controlled documentation. Changes are made directly in the document, and the rationale for those changes is discussed through comments. A manager reviews the comments, provides feedback, and either accepts or rejects the proposed changes.

We also maintain a changelog within the live document using a database. After all changes have been reviewed, the document must go through a formal sign-off process.

In the past, we managed documents in Microsoft Word using Track Changes. This made it very easy for the sign-off manager to see exactly what had changed between approved versions. We are trying to achieve a similar level of transparency in Confluence, but I have a few concerns regarding Version History:

1. Creation of versions seems unpredictable

Confluence appears to decide automatically when a new version is created. Sometimes a new version is generated when multiple people are working in the document, while at other times similar edits do not seem to create a new version immediately.

In addition, there can be a considerable delay before a new version appears.

This creates challenges for our review process because:

* Multiple authors may be working in the document simultaneously.
* A single review cycle can result in dozens of versions.
* It becomes difficult for the sign-off manager to identify which versions should actually be compared.

Is there a way to manually create, label, or request a new version at a specific point in time, similar to creating a controlled revision?

2. Compare Versions behaves inconsistently

When using Compare Versions, the output differs between documents.

In some live documents, almost all content appears as struck through, which makes it look as though everything has been removed. In other documents, changes are displayed much more clearly, with additions highlighted in green and text shown as inserted, modified, or deleted.

As a result:

* I am not always confident that I am interpreting the comparison correctly.
* I am unsure whether all changes are actually being displayed.
* I do not know how to verify that the comparison is complete and accurate.

Is this a known limitation of Confluence's comparison engine, particularly for Live Docs or pages edited by multiple users?

3. Best practice for formal approvals

For organizations that require document review, approval, and sign-off:

* Do you rely on Version History alone?
* Do you maintain a separate changelog?
* Are there recommended apps or workflows that provide functionality similar to Microsoft Word's Track Changes?

I would appreciate any guidance or examples of how others manage controlled documents and sign-off processes in Confluence.

Abaho Katabarwa (Katabarwa Labs) · Answer

One thing worth adding to Tobi's point about native Approvals, because it matters for your case specifically: approvals work on pages, not on live docs. Since your controlled document is a live doc, converting it is the prerequisite step, not an optional tidy-up. It is on the document itself, under ... (More actions) > Convert to page.

That conversion also answers your first question as a side effect. A page has an explicit Publish, so a version is created when someone publishes rather than by background autosave consolidation, which is exactly why live doc version timing looks arbitrary and why entries appear late. On a page you can also label a version and add a comment when publishing, so your sign-off manager can tell which two revisions are the ones to compare instead of guessing among dozens.

On the changelog you keep in a database: be aware that approval state does not currently surface as a field in Confluence databases, so you cannot build a database view that tracks which pages are approved and which have changed since approval. A request for exactly that has just been raised as CONFCLOUD-85216. Given that your changelog-in-a-database is that use case, it is worth voting and watching so you hear when it moves.

James Gamble · Answer

Hola Loes,

Version History is useful as an audit trail, but I wouldn't use it as the approval process itself. The version behavior you're seeing with Live Docs is expected. Atlassian says a Live Doc creates a version when editing begins and finalizes it about 10–15 minutes after the last edit. Because there's no explicit publish point, those versions don't line up neatly with a controlled review cycle.

For controlled documentation, I'd move these documents to regular Confluence pages. Pages have a draft/publish model and version history, and Atlassian specifically recommends them for structured, reviewable content such as policies and specifications that require approvals.

Since you're also looking for a formal sign-off, Confluence's native Approvals feature is probably the next thing I'd evaluate if you're on the Premium or Enterprise plan. It records the approvers, their decisions, comments, and approval history. However, it also only works with pages, not Live Docs.

For the comparison issue where most of the document appears struck through, I wouldn't assume that's normal behavior. If it still happens after moving the content to a regular page, I'd capture a couple of examples of affected pages and raise it separately with Atlassian Support.

Thanks,

James

Tomislav Tobijas · Answer

@Peters, Loes (Lloyds Bank - Nederland) One additional option worth mentioning: Confluence now has native Approvals in Open Beta for Premium and Enterprise customers. 🆕

Approvals provide a formal sign-off process directly on the page, with named approvers, approval decisions, comments and an activity history.

The latest update also allows approval to be required before every publish, including edits to existing pages, which makes this much more suitable for controlled documentation.

One limitation: approvals currently work on pages, not Live Docs. 🫤

Cheers,

Tobi