Confluence vs SharePoint page approvals: what readers see before signoff

SharePoint’s modern page approval flow explicitly covers new and updated pages, with draft versioning required. Confluence Cloud’s native approvals record signoff, but its documented rule requiring approval before publication specifically describes new pages. If your team needs to hide every revision until review, check the existing-page behavior in your Confluence space before depending on that rule. Microsoft’s page approval guide, Atlassian’s approval guide

The important purchase question is what staff can read while a replacement instruction is waiting. A signoff on the original page will not answer that question for its next revision.

What each workflow promises

Confluence approvals require Cloud Premium or Enterprise and apply to pages, excluding live docs and blog posts. Reviewers can approve or request changes; the activity log records earlier cycles and decisions. Its published-page status and draft status are managed separately. Atlassian’s approval guide

For SharePoint modern pages, the author submits a new page or revision for approval. Approval publishes it; rejection returns it to draft. Microsoft requires major and minor draft versions and says the approval flow controls when changes become visible to site readers. Microsoft’s page approval guide

Those descriptions support different conclusions. SharePoint expressly documents the updated-page publishing rule. Confluence’s narrower wording leaves a question to resolve in the actual space; it does not prove that edited-page enforcement is impossible.

Set up the correct page feature

In Confluence, a space admin uses Status and approvals, enables statuses with approvals, and configures the publishing requirement. The required-approvers setting can enforce a list of up to five people across the space. A page editor starts an individual request from the content status menu, adds approvers and context, and starts the approval. Confirm who is permitted to request and respond: edit permission is required. Atlassian’s setup instructions

SharePoint’s documented route applies to communication sites and modern team sites. A site owner opens the Pages library, then selects Automate > Power Automate > Configure page approval flow > Create flow. Specify the flow name and approvers, who should be site owners or have full control or edit permissions. Check the library’s major and minor versioning prerequisite separately. Microsoft’s configuration guide

The SharePoint setup affects all site pages. Before applying it to a busy site, ask whether routine announcements and formal operating instructions should follow the same approval process. A team wanting review for one policy may otherwise introduce an unexpected waiting step for ordinary news.

Also distinguish a modern page from a file in a document library. Microsoft’s separate modern list and document library approvals have their own rules, including cancellation of a pending request after an edit. That rule cannot be carried across to the page flow. Microsoft’s list and library approval guide

Follow a revised service desk instruction

Suppose a small team already has this approved instruction:

For requests received before 4 p.m., reply on the same working day.

Staffing changes, and the owner proposes:

For requests received before 2 p.m., reply on the same working day.

This is a hypothetical page, not a result observed in either product. The owner wants staff opening their existing bookmark to keep seeing the approved 4 p.m. wording while the revision waits. The approver, however, needs to see the proposed 2 p.m. wording.

Write those two views down before configuring the flow. Otherwise, a pilot can appear successful because the reviewer received an email, even though nobody checked the staff member’s page.

The first draft also contains an inconsistency. It says one person handles the afternoon queue, while the proposed procedure assigns an intake owner and a backup reviewer. The reviewer reads the full changed passage, requests changes, and explains which responsibilities are unclear. A decision based solely on the cutoff sentence would miss the operational problem.

The editor corrects the responsibilities and adds:

After 2 p.m., assign the request to the next working day’s queue.

That corrected revision needs its own review. After signoff, check that staff see the 2 p.m. cutoff and the afternoon-queue instruction. Check the coverage paragraph too. A page that publishes only one of the intended changes could leave staff with contradictory instructions despite an approval record.

The review message can be specific:

Review the cutoff change from 4 p.m. to 2 p.m., the afternoon-queue sentence, and the intake owner and backup reviewer responsibilities. The existing instruction should remain reader-visible until this revision is approved.

That message gives the approver something concrete to inspect. It also states the required reader outcome without claiming that a notification itself enforces it.

Run the pilot through a second revision

The page approval pilot CSV contains eight cases. Its expected-reader column states requirements for this example; the observed-result column is empty for your team’s actual observations.

Start by opening the approved baseline as an ordinary reader. Use a reader who lacks the editor’s extra permissions, and open the same bookmark staff already use. Record the displayed sentence.

Create a separate new-page draft. This answers the first-publication question independently of the existing-page revision. Then change the baseline to 2 p.m., submit it, and revisit the reader account while the request is pending.

Have the reviewer open the submission with their own account. Check the exact sentence and coverage paragraph they can read. Request changes or reject it, revise the draft, and submit again. After approval, read the final wording through the ordinary account.

Now propose a further change to 1 p.m. This catches a configuration that behaved correctly on the first approval but lets a later edit inherit the earlier signoff. Record what happens instead of assuming the first successful cycle proves every subsequent revision.

The eighth case covers an unavailable approver. Ask the owner how the actual flow handles that absence and who may authorize a replacement. Verify whether its configured approvers act in sequence or together and how completion is determined. The cited page instructions do not settle every customized flow’s quorum or later-edit behavior. An elapsed due date should not be treated as a recorded approval.

Keep the approved page accessible while arranging the pilot. If the old instruction becomes urgently wrong, the responsible team needs to communicate the temporary operating instruction; these support pages do not establish an emergency publishing bypass.

Keep the decision retrievable

For each revision, retain the page location, changed passage, approvers’ decision, and the version readers finally saw. A later question about the 2 p.m. cutoff should be answerable without interpreting an unrelated signoff on the earlier 4 p.m. page.

When reviewing an existing SharePoint setup, inspect both content approval and its Power Automate flow. Turning off content approval in Versioning settings does not delete the flow. Deleting the flow is a separate permanent operation. Microsoft’s configuration guide

The workflow descriptions were checked against the linked official documentation on October 7, 2026. No live Confluence or SharePoint tenant was tested. Before using either system for revised operating guidance, fill the pilot’s observed-result column with the actual reader and reviewer views, including that second revision.