I’m researching how teams manage a situation where different Confluence pages document the same policy, process, or technical decision but contain incompatible instructions. Because all those pages can continue appearing in search results or Rovo answers, I would like to understand how teams currently: * discover that two pages contradict each other; * decide which page is authoritative; * prevent employees or Rovo from continuing to use the rejected version; * record who made that decision and why. Is this a recurring operational problem in your organization? If so, how do you solve it today, and what part of the process requires the most manual work?

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do teams handle conflicting documentation and define the authoritative source in Confluence?

Ricardo_7vk5a6

I’m researching how teams manage a situation where different Confluence pages document the same policy, process, or technical decision but contain incompatible instructions.

Because all those pages can continue appearing in search results or Rovo answers, I would like to understand how teams currently:

discover that two pages contradict each other;
decide which page is authoritative;
prevent employees or Rovo from continuing to use the rejected version;
record who made that decision and why.

Is this a recurring operational problem in your organization? If so, how do you solve it today, and what part of the process requires the most manual work?

Accepted answers

James Gamble_qdhhly

Hola Ricardo,

Yes, this is a recurring documentation-governance problem, especially when teams can create pages freely across multiple spaces. Confluence can help manage the content, but it doesn't automatically identify that two pages contain contradictory instructions or designate one as the authoritative version.

The approach I've seen work best is to assign a clear owner to each policy, process, or technical domain, and maintain a single published page as the source of truth. The page owner is responsible for reviewing changes, resolving conflicts with relevant stakeholders, and keeping the authoritative page up to date. Confluence supports transferring page ownership, adding a content status, and retaining the page history so teams can see who changed the content and when.

Once a page has been rejected or superseded, I'd avoid leaving it published with only a warning banner. Archive it, or restrict access if it must remain available for audit purposes. Archiving removes outdated content from the normal content tree and helps reduce the chance that employees will continue to find it through everyday searches. Atlassian's guidance on archiving is here.

For the authoritative page, I'd include the owner, approval status, last review date, next review date, and a link to the decision or Jira work item that records why the conflicting version was rejected. Confluence's version history records edits, but it won't necessarily capture the business rationale unless the team explicitly records it.

The most manual parts are usually discovering that the contradiction exists and getting the right owners to agree on the final wording. Content Manager can help locate stale pages, change owners, update statuses, and archive content in bulk, but someone still has to evaluate whether the information is correct.

Rovo's answers should also be reviewed in light of the sources they cite, since they are based on information the user can access. Leaving both versions available creates a real possibility that either will influence the response. I'm not aware of a native setting that marks one Confluence page as globally authoritative and forces Rovo to ignore all conflicting pages, so removing or restricting the rejected content is important.

Thanks,

James

Mia Tamm

Hi @Ricardo,

This is a really interesting problem, especially the distinction between detecting a contradiction and governing what happens after it has been identified.

I wonder if part of the answer could be making the decision itself structured metadata on the page, for example:

Authority status: Authoritative / Superseded / Deprecated
Superseded by: canonical page
Decision owner
Decision date
Reason

That wouldn't solve the automatic detection of conflicting content, of course, but it could make the resolution explicit, reportable and auditable once a decision has been made.

I'm particularly curious about one thing: once your team decides that Page A is authoritative and Page B is no longer valid, what do you do with Page B today?

Do you archive it, add a warning, restrict it, redirect users somehow, or keep it available for historical reasons?

We're looking quite closely at how structured information around Confluence pages can help with problems like this, so I'd be very interested to understand how teams handle that last step in practice.

All comments

James Gamble_qdhhly

Hola Ricardo,

Thanks,

James

Ricardo_7vk5a6

Thanks, James — this is very helpful.

When you say that discovering contradictions is usually still manual, are you aware of any Marketplace app that scans across spaces and flags potentially conflicting pages for a person to review, or do teams generally discover these conflicts only after someone encounters them?

Mia Tamm

Hi @Ricardo,

This is a really interesting problem, especially the distinction between detecting a contradiction and governing what happens after it has been identified.

I wonder if part of the answer could be making the decision itself structured metadata on the page, for example:

Authority status: Authoritative / Superseded / Deprecated
Superseded by: canonical page
Decision owner
Decision date
Reason

That wouldn't solve the automatic detection of conflicting content, of course, but it could make the resolution explicit, reportable and auditable once a decision has been made.

I'm particularly curious about one thing: once your team decides that Page A is authoritative and Page B is no longer valid, what do you do with Page B today?

Do you archive it, add a warning, restrict it, redirect users somehow, or keep it available for historical reasons?

Ricardo_7vk5a6

Thanks, Mia that distinction is exactly what I’m exploring.

The structured metadata you describe seems particularly useful once a conflict has already been identified. The part I’ve been focusing on is the step immediately before that: automatically surfacing pairs of Confluence pages that may contain incompatible claims, showing the relevant passages, and then letting a person choose the authoritative version.

I’ve built a small Forge prototype around that workflow, where the human decision is saved and the selected and rejected sources are classified accordingly.

From your experience with Confluence customers, do you see more difficulty in discovering conflicting pages in the first place, or in governing what happens after the conflict is found?

Mia Tamm

From what I’ve seen, discovery is usually the harder part.

Once two conflicting pages are put in front of the right person, deciding which one is authoritative is often manageable. The real problem is that nobody knows the conflict exists until someone stumbles across it.

Your prototype sounds useful because it attacks exactly that invisible part of the problem. I’d be especially interested in false positives though — if it flags too many “maybe conflicts”, people will probably stop trusting it quite quickly.

Ricardo_7vk5a6

That concern about false positives is exactly the threshold I’ve been trying to get right.

The prototype currently discards ambiguous or low-confidence results and only surfaces candidate conflicts together with the exact passages that triggered the comparison. The final decision is always left to a person.

I’m currently looking for a small number of real-world Confluence environments to validate that behaviour outside my test data. If you’d be open to it, I’d be happy to show you the current private beta or let you try it and get your feedback specifically on whether the false-positive rate feels acceptable in practice.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

confluence-cloud

rovo