In this page

A more comprehensive list of changes on the cloud platform

The following is a list of differences between the self-hosted and cloud versions of the app, organized by key concepts and features. This guide assumes prior experience with the self-hosted version of the app.

Overall high level changes

These decisions affect many aspects of the app and user interface, understanding them should make it easier to grasp all other changes in app usage and behavior.

  • Besides pages, blog posts are also fully supported.
  • Instead of traversing page trees and building internal caches, the app relies on the Confluence index, which can be queried by CQL expressions.
  • Instead of labels, the app stores metadata in page and space properties, not directly visible to the user, but mostly available as CQL fields.
  • Instead of relying on the built-in job running mechanism of Confluence (server / data center), the app now implements its own scheduling and job running platform.

Page status / content status

  • The concept of content status is much more flexible on cloud.
    • You can configure custom statuses defined by arbitrary CQL expressions, with custom colors and icons.
    • Statuses are immediately available as CQL fields, so you can easily find all contents matching a specific status. You can see the available CQL fields and their values for any content in the Content Status Indicator → Status details → CQL fields tab.
  • Attachments do not affect the "last updated" value of a page.
  • You can track when a content last changed its status or easily collect contents whose status changed in the specified time window (see arch.previousStatus, arch.previousStatus.id and arch.status.changedOn fields).
Content quality
  • Page Status Indicator is called Content Status Indicator.
  • No "per space group" stats, but you can filter the content status overview on schemes.
  • On the self-hosted platform, the "Better Content Archiving: Analyze Content Quality" job runs every 2 hours, which can be changed. On cloud, however, the schedule rate for this job is fixed, but you can run the job manually (for a single space or for all spaces) and you can schedule notifications and automations in a flexible way, via cron expressions.
  • No dedicated screen for "statuses of all pages", but you can create a macro that lists contents and their statuses, and you can even fine-tune the list of contents shown by it.
Quick actions
  • No label-based workings, content properties are set and used by the app (though you can still configure schemes to use labels, because labels are fully supported in CQL expressions!).
  • No "discuss" and "jump to ancestor" quick actions.
  • No quick actions in emails.

Jobs

  • Jobs are organized differently, with clearer scopes of responsibility.
  • There is a dedicated job screen under the app's global config screen.
  • There is no way to directly modify the scheduling of jobs themselves, but you can configure the schedules of notifications and automations in the corresponding schemes. The scheduling mechanism will then choose to run the appropriate job whenever required by the scheme configuration.
  • Job execution results are not as detailed as in the self-hosted app, but they still show key statistics of operations performed (specific to the given job's type, e.g. “emails sent” shows the count of emails sent as a result of executing the Send notifications job).
Initialization, content status calculation
  • Initialize content events job:
    • No need to pick a strategy on how to initialize the "last viewed" value for each piece of content; if unset, it is initialized with the date of the last update.
    • Runs every week automatically to ensure data integrity.
  • Refresh content statuses job:
    • Runs automatically on a schedule that depends on the app license type.
    • Can also be started manually any time, like on the self-hosted platform.

Configuration

  • Archiving configs have been replaced with schemes (split by app features).
    • You can define separate schemes for statuses, notifications, and archiving/deletion (automation) rules. They are not tightly coupled like on self-hosted (archiving rules and the corresponding notifications, for example). You can freely choose and assign any scheme of a specific type to any space.
    • There are no custom configs. You can instead apply schemes to spaces in a flexible way (set a default scheme or apply other schemes to spaces individually).
  • It’s not possible to have more than 10 schemes, so it's not possible to create a unique one for each space if there are more than 10 spaces.
  • Action triggers are replaced with CQL expressions (and cron expressions, where applicable).
  • You can apply a default scheme to a space either implicitly or explicitly:
    • Implicit assignment means that the space has not been assigned manually to any scheme, so it simply uses the default one. If you choose another one as default, the implicit assignment will point to that, automatically.
    • Explicit assignment means that the space has been manually assigned to a scheme that also happens to be the currently default one. If you select another one as default, the explicit assignment will keep pointing to the old one.
    • When a new space is created, it is assigned to the default scheme implicitly.
Page view tracking
  • No labels to override app behavior, content properties are used for that by the app (though you can still configure schemes to use labels, because labels are fully supported in CQL expressions!).
  • No "no view" functionality and no "archive" quick link in emails.
  • Equivalent schemes can be defined for page view tracking purposes, but they are much more flexible than just that.
Page expiration tracking
  • No labels to override app behavior, content properties are used for that by the app (though you can still configure schemes to use labels, because labels are fully supported in CQL expressions!).
  • No edit or archive quick links in emails.
  • Equivalent schemes can be defined for page expiration tracking purposes, but they are much more flexible than just that.
Archiving
  • Configuration options are much more flexible (archiving action and notifications are separated, for example).
  • The app build on top of Confluence Cloud's built-in archiving feature instead of a custom archiving implementation. Consequences:
    • No separate “archive space” is created by the app, therefore there are no "copy and trash" or "move" archiving strategies. The equivalents of archiving strategies are called "automation actions" on cloud; an automation action can be "archive" (paid Confluence plan required) or "delete".
    • Labels are left unchanged when archiving.
    • No app-specific way to work with archived content (like search and restore) because of using the built-in archiving feature.
    • No custom-specified archiving actor who performs the archiving operation (cloud apps have their own, dedicated user).
  • No "Archiving reason required" flag when marking a page for archiving.
  • No labels to control archiving, only quick actions (based on content properties) and schemes can be used.

Global settings

  • No "Trusted group".
  • No "default config".
    • Instead, default schemes can be selected for each scheme type, separately.
    • Instead of the optional "default archiving configuration", default schemes are automatically used in newly created spaces out-of-the-box (i.e. you will always have a default scheme that is implicitly applied to the new space).
    • Changing the default scheme affects all spaces that are using the default scheme (implicitly, not explicitly!), unlike on the self-hosted platform where it only affects spaces created afterwards.
  • Username visibility is controlled by Confluence Cloud when persisting content events.
  • No system properties on cloud, of course.

Blacklisted spaces

  • Changed terminology: "excluded space" instead of "blacklisted space".
  • All other concepts are essentially the same.

Notification emails

  • Triggers are more flexible; no "space creator" and "space supervisor" addressees, but users and groups can be added.
  • Notification emails can be customized, similar to how it is done on the self-hosted platform, but with different syntax (Handlebars instead of Velocity) and with minor differences like the absence of certain quick links.
  • There are sensible default templates that are a great starting point for any customization you may need.

Performance tuning

  • Blacklisting/excluding spaces is driven by the same principles on both platforms.
  • Optimizing schedules (not too often, not too rarely): scheduling notifications and automations can be configured using cron expressions; you can apply any consideration you did on the self-hosted platform.

API

  • The app provides no public API on cloud.
  • App provided CQL fields are generally available, so they can be used by any external tool that supports CQL queries.

Questions?

Ask us any time.