Three Confluence Policies Disagree. Which One Is the Rule?

A department copies a policy into its Confluence space because the original is difficult to find. Another team adds an explanation for its own work. A third changes an approval step that no longer seems practical. Each edit looks helpful in isolation.

Later, an employee searches for the policy and finds three official-looking pages giving different answers.

Merging them sounds like a sensible cleanup. But the editor immediately faces a question no amount of better wording can answer: which instruction should survive? The organization has a disagreement about the rule, not merely duplicate paragraphs.

A timestamp cannot choose the approval path

Take two fictional internal instructions about application access:

Onboarding page: Ask your line manager to approve access before submitting the request.

Operating handbook: Submit the request directly. The application owner approves it in the service portal.

These aren't actual policy quotations or legal requirements. They illustrate the kind of disagreement a reader has to resolve before acting. Perhaps the handbook replaced the old process. Perhaps the instructions apply to different groups. Perhaps someone changed the local page without an accepted policy decision.

The handbook's more recent edit date doesn't distinguish those possibilities. It could reflect an approved revision, a spelling correction, or a workaround. Combining both instructions would preserve the contradiction inside one cleaner page; choosing the sentence that reads better would make a policy decision through copyediting.

I would ask the responsible policy owner to establish which route applies, to whom, and from when. The pages and their histories help examine that question. They don't become authoritative simply because their formatting is more polished. Confluence supplies tools for creating and organizing content; those tools still need the organization's meaning attached to what is published. [1][2]

One rule can have several entrances

Once the access route is settled, the onboarding page still has a useful job. A new colleague may naturally begin there rather than in a central policy space. Removing the local explanation altogether could recreate the findability problem that caused the copy.

The better distinction is between a route to the policy and a competing version of it. The onboarding page might explain that application access is requested through the service portal, then link to the maintained procedure for the actual approval requirements. That gives the reader context without reproducing every rule in another place.

A detailed local summary is also possible when someone will maintain it. The cost should be understood: a functioning link doesn't keep an independently written explanation accurate after the governing process changes. Sometimes a shorter signpost is the more dependable choice.

The objective is one maintained answer with useful ways to reach it, not one enormous page expected to serve every reader's situation.

Old instructions need a different kind of visibility

An earlier approval rule may still explain why a team acted as it did last year. Deleting every historical page would remove that context. Leaving it indistinguishable from current guidance would create another problem.

A historical version can retain its value when its status and successor are clear. The ordinary routes into today's work—onboarding links, service instructions, search results, and familiar bookmarks—should lead readers to an answer they can interpret correctly. Archiving a duplicate is not enough if a commonly used procedure still sends employees to it without explanation.

The test is therefore less about the page count than the next reader. Can someone following the old onboarding link tell which instruction governs their request now? Can they understand the relevant exception without finding a colleague who remembers the cleanup?

The next correction matters more than the merge

The original contributor probably copied the policy because helping their team was easier than updating the central source. If that remains true, another copy will be a tempting response to the next outdated step.

A visible, usable route for proposing a correction gives that contribution somewhere better to go. The policy owner can accept it, explain why it doesn't apply, or clarify the rule. Routine wording fixes needn't become committee work; consequential changes to an approval path do need the appropriate decision.

The merge is finished when the employee can find the applicable instruction and the next contributor can improve it without starting a rival version. Otherwise Confluence contains the documents, but the practical source of truth is still whoever happens to answer in chat.