In this page

FAQ

1 - Why doesn't the content status of my page reflect a recent change?

Better Content Archiving uses CQL searches to determine content status. Confluence's CQL indexing service updates those search results. It normally picks up changes within seconds, but under load it can take several minutes. While indexing is delayed, a page's status may not immediately reflect recent changes.

For example, if a page is currently "Expired" and you update it, it may still display "Expired" immediately after the edit. After the CQL index catches up (from a few seconds to a few minutes), just force a status refresh by opening the Content Status Indicator, and the status will change to "Up-to-date", as expected.

This latency is a technical limitation of Confluence's CQL indexing service, not an issue with Better Content Archiving. You can test this yourself without using the app:

  1. Add a label to any page.
  2. Immediately search for that page using the CQL query label="your-label".
  3. If the page doesn't appear right away in search results, it means CQL indexing is delayed.
  4. Keep trying the search. When the page appears, that means the CQL index has updated.
  5. (The time between 1 and 4 is the current latency.)

Ultimately, minimizing such delays depends on Atlassian improving the CQL indexing service. You can indicate its importance by voting for and commenting on AI-920.

2 - Why can't I see the content status on space homepages?

According to Atlassian, space homepages are designed as simplified landing pages for quick access and general overviews. They intentionally omit detailed page information (e.g. author, last updated date, commonly known as byline items) shown under the page title.

Better Content Archiving does not display page status on homepages due to their simplified design. However, the app still processes homepages in the background, including status calculation, page view tracking and such, which means they can potentially expire.

As its content status is not directly visible on the homepage, we think excluding them from the content lifecycle management can be beneficial to avoid confusion.

You can do that by modifying the CQL condition of the "Excluded" status:

  • To exclude homepages via their name, add the or title ~ "Home" clause to the CQL. It assumes that your homepages are named "... Home", which is the default name in English.
  • To exclude homepages via their ID, add the or id=12345 clause to the CQL. Don't forget to use the actual ID of the homepage (how to find the ID?).
  • To exclude homepages via a specific label, add or label="foo" clause to the CQL. Plus, add the "foo" label to the homepages and other pages you want to exclude. Use any label name that is intuitive and is not used for other purposes on your Confluence site. (If you have a large number of pages to label this way, you can even create an automation rule or a script that does it through the REST API.)

Note: best would be if CQL supported an isHomePage field or a parent is empty clause, but none of these are supported right now. ☹️

Finally, if you agree that homepages should be treated the same way as normal pages, vote for and leave a comment on CONFCLOUD-77845.

3 - What's the difference between the Midori owner and the limited owner (Atlassian owner)?

Brief history first. Better Content Archiving introduced the "content owner" concept in the 8.8.0 release in 2020. Atlassian added a limited "owner" feature in Confluence Cloud five years later, in 2025. Because Atlassian used the exact same term "owner", this can be confusing.

There are two major differences between the Midori owner and the limited owner:

  1. A content can have zero, one or multiple Midori owners, but it always has exactly one limited owner.
    Adding multiple Midori owners is an option to represent shared content responsibility. Adding zero Midori owners is an option to mark the content "ownerless".
  2. Midori owners can be inherited from a parent page to its descendants, while limited owners can not.
    Inherited Midori owners make ownership management more consistent in large hierarchical content trees.

How does it affect you in practice?

  1. When you use the Set owner quick action, you are setting the Midori owner.
  2. When you use the Change owner button, you are setting the limited owner.
  3. When you see "owner" on the app's user interface (e.g. on the Content Status Indicator or at the notification recipients), it means the Midori owner.
  4. When running CQL searches, you can search for both using two separate CQL fields:
    1. Midori owner: arch.anyOwner = currentUser() (more examples)
    2. limited owner: owner = currentUser()

Learn more about managing content ownership in this blog post.

Questions?

Ask us any time.