In this page

Changes in depth

This page provides a detailed breakdown of the changes in the cloud version of the Better Content Archiving app. Unlike previous comparisons, it also includes the finer details and even some important technical aspects.

Use this reference to understand how certain functionalities may differ or operate uniquely in the cloud. Whether you're troubleshooting or optimizing your setup, this comprehensive list will help you navigate the finer points of the Cloud version.

CQL everywhere

  • Instead of traversing page trees, the app uses the Confluence index, which is much faster and supports flexible queries.
  • The Confluence index can be queried by CQL. CQL is used extensively in the app — it can select a set of contents that should be assigned with a status, included in a notification message, archived/deleted, and more.

Contents and statuses

The cloud app supports more content types and offers much greater flexibility when it comes to configuration.

Content status (page status / blog post status)
  • In addition to pages, blog posts are fully supported.
  • While the self-hosted app utilizes standard Confluence labels to mark pages, the cloud app stores metadata in page and space properties instead. These properties aren't directly visible to users (like labels do) but are accessible through CQL fields. That makes properties more expressive and powerful than labels.
  • While the self-hosted app only provided a pre-defined set of statuses, the concept of content status is much more flexible in the cloud version:
    • You can define custom statuses using any CQL expression, and assign custom colors and icons to them.
    • Statuses are available as CQL fields, making it easy to find all content with a specific status. To view the available fields and their values for a content, go to the Content Status Indicator → Status details → CQL fields tab.
    • You can also track when a content's status last changed, or find items whose status changed within a specific time window using fields like arch.previousStatus, arch.previousStatus.id and arch.status.changedOn fields.
  • It is worth mentioning that attachments do not affect a content’s “last updated” value.
Content quality
  • Page Status Indicator is called Content Status Indicator on the cloud, to reflect the added support for blog posts.
    • The Content Status Indicator is not available if the page is the home page of a space. This is a technical limitation at the moment of writing.
  • No space grouping (like in the self-hosted Content Quality / Quality Statistics screen), but you can filter the content status overview on schemes. On the cloud, you also get powerful reporting features.
  • On the self-hosted platform, the Better Content Archiving: Analyze Content Quality job runs every 2 hours by default, and this interval can be customized. In the cloud version, the schedule for the corresponding job (Refresh Content Statuses) is fixed — but you can run it manually for a single space or all spaces. Notifications and automations can be scheduled flexibly using cron expressions.
  • There’s no dedicated Content Status Browser in the cloud, but you can use macros to list content along with their statuses—and you can fine-tune which items appear in the list.
Quick actions
  • Lifecycle changes like immediate or scheduled expiration are not managed with Confluence labels in the cloud version. Instead, the app uses content properties. However, you can still configure schemes to use labels, as labels are fully supported in CQL expressions.
  • No Discuss quick action.
  • No quick actions in email notifications.

Configuration

As mentioned earlier, the cloud version offers much more flexible tools for modeling your content lifecycle. Other features, like global settings and space exclusion, work in almost the same way as in the self-hosted version.

Schemes
  • Archiving configurations have been replaced with separate schemes, each focused on a specific app feature.
    • You define separate schemes for statuses, notifications, and automation rules (archiving/deletion). Unlike the self-hosted version, these are not tightly coupled—for example, archiving rules and their related notifications are managed independently. You can assign any scheme of a given type to any space as needed.
    • Custom archiving configurations for spaces no longer exist in the cloud. Instead, you can assign schemes flexibly – either set a default scheme or apply different schemes to individual spaces.
      • You can’t create more than 10 schemes of each type, so it's not possible to assign a unique scheme to every space if you have more than 10 spaces.
    • Action triggers have been replaced with CQL expressions – and with cron expressions where scheduling is needed.
  • You can apply a default scheme to a space either implicitly or explicitly:
    • Implicit assignment means the space hasn’t been manually assigned to any scheme, so it automatically uses the default scheme. If you change the default, the implicit assignment will automatically point to the new default.
      • When a new space is created, it is assigned to the default scheme implicitly, until you assign it manually to another scheme.
    • Explicit assignment means the space has been manually assigned to a scheme, even if it's currently the default one. If you change the default, the explicit assignment will still point to the original scheme, instead of the new default.
Page view tracking
  • No "no view" functionality and no "archive" quick link in email notifications.
  • Schemes offer a much more flexible approach to defining view tracking lifecycle rules.
Page expiration tracking
  • Lifecycle changes like immediate or scheduled expiration are not managed with Confluence labels in the cloud version. Instead, the app uses content properties. However, you can still configure schemes to use labels, as labels are fully supported in CQL expressions.
  • No "edit" or "archive" quick links in notification emails.
  • Schemes offer a much more flexible approach to defining expiration tracking lifecycle rules.
Archiving
  • The app builds on top of Confluence Cloud's built-in archiving feature instead of a custom archiving implementation. This has the following consequences:
    • No separate “archive space” is created by the app, therefore there are no "copy and trash" or "move" archiving strategies. In the cloud version, their equivalents are called "automation actions," which can be either "archive" (requires a paid Confluence plan) or "delete".
    • Labels remain unchanged when content is archived.
    • There’s no app-specific way to search or restore archived content, as the app relies on Confluence’s built-in archiving feature.
    • Unlike the self-hosted version, you can’t specify a custom archiving actor – cloud apps use their own dedicated system user to perform archiving actions.
  • There is no "Archiving reason required" option when marking a page for archiving in the cloud version.
  • Lifecycle changes like immediate or scheduled archiving are not managed with Confluence labels in the cloud version. Instead, the app uses content properties. However, you can still configure schemes to use labels, as labels are fully supported in CQL expressions.
  • Automation schemes offer a much more flexible approach to defining archiving lifecycle rules (archiving action and notifications are separated, for example).
Global settings
  • There is no Trusted group on cloud.
  • There is no default config.
    • Instead, you can select default schemes separately for each scheme type.
    • These default schemes are automatically applied to newly created spaces without any extra setup.
    • If you change a default scheme, all spaces using it implicitly will switch to the new one – unlike on self-hosted, where changes only affected future spaces.
  • Naturally, system properties are not available in the cloud environment. Usernames can be hidden using the available UI controls, if needed.
Blacklisted spaces
  • Blacklisted spaces are now referred to as excluded spaces. The concept remains the same.
Notification emails
  • Triggers are more flexible; instead of space creator and space supervisor addressees, you can now specify users and groups.
  • Notification emails can be customized, similar to the self-hosted version, but using different syntax (Handlebars instead of Velocity) and with slight differences, such as the absence of certain quick links.
  • The app provides sensible default templates, which are a great starting point for any customization you need.

Jobs

  • Instead of relying on Confluence’s built-in job scheduling (like on the self-hosted platform), the app uses its own scheduling and job execution implementation, completely independent of Confluence.
  • Jobs are organized differently, with clearer scopes of responsibility.
  • A dedicated job screen is available under the app’s global configuration.
  • You can’t directly modify job schedules, but you can configure the schedules for notifications and automations in their respective schemes. The scheduling system will then automatically trigger the relevant job based on the scheme configuration.
  • Job execution results are less detailed than in the self-hosted version, but they still provide key statistics specific to each job type (e.g., “emails sent” shows the number of emails sent as a result of the Send notifications job).
Initialization and content status calculation
  • On the cloud, the Initialize content events job handles content status initialization:
    • There's no need to choose a strategy for initializing the last viewed value; if it's unset, it will be initialized with the date of the last update.
    • Runs automatically every week to ensure data integrity.
  • On the cloud, the Refresh content statuses job periodically refreshes the status of all contents:
    • Runs automatically according to a schedule based on the app's license type. For free apps, it will run less frequently to save computing resources.
    • Can also be manually triggered at any time, just like in the self-hosted platform.

Performance tuning

  • Excluding spaces follows the same principles on both platforms.
  • Optimize schedules by configuring notifications and automations with cron expressions; you can apply the same considerations you used on the self-hosted platform.

API

  • The app does not provide a public API on the cloud.
  • However, CQL fields provided by the app are generally available and can be used by any external tool that supports CQL queries.

Questions?

Ask us any time.