Issue Summary

An Enterprise Confluence Cloud customer uses many Confluence Automation rules with a Page condition filtered by a specific content status (for example, "Expired-Needs Review").

Over time, these rules end up in a broken state where the Page condition:

• No longer displays the configured content status value, and

• Shows the error in the rule editor:
  “We could not find the specified content statuses. Please try again.”

This occurs even though the underlying content status still exists in the space configuration and can be selected again. The customer reports this happening across 100+ rules in 100+ spaces, and support has reproduced the broken-condition state on at least one example rule.

Steps to Reproduce

1. In a Confluence Cloud site, configure a space with a custom content status, for example:
   Expired-Needs Review.

1. Create a global Confluence Automation rule scoped only to that space.

• • Trigger: Scheduled (e.g., run weekly or on a specific date).

• • Condition: Page condition →
    Where: Page status is one of "Expired-Needs Review".

• • Action: Any (e.g., update page status, archive page, etc.).

1. Save the rule. Confirm in the rule editor that:

• • The Page condition shows "Expired-Needs Review" selected.

• • There are no errors shown in the condition.

1. Ensure that the underlying content status (Expired-Needs Review) still exists in the space configuration.
   (It is not deleted or renamed; it is still visible and selectable in the status configuration UI.)

1. Wait some time (days/weeks) and later open the same rule again in the Automation editor.

1. Inspect the Page condition in the rule.

Expected Results

• As long as the underlying content status (for example, "Expired-Needs Review") exists in the space configuration, the Page condition should:

• • Continue to display that status value in the rule editor, and

• • Remain valid over time, even if currently 0 pages are using that status in the space.

• If the status becomes invalid (for example, truly deleted or changed in a way that breaks the reference), the rule/editor should:

• • Clearly indicate that the configured status is invalid, and

• • Record a clear field‑level change in the Audit log explaining what changed.

Actual Results

• After some time, the rule’s Page condition loses its configured status value and ends up in a broken state:

• • No status value is shown in the Page status is one of field.

• • The editor displays the error message:
    “We could not find the specified content statuses. Please try again.”

• In the affected space(s):

• • The content status (e.g., "Expired-Needs Review") still exists in the Content Status configuration.

• • It is still selectable in the Page condition dropdown when editing the rule.

• The rule’s Audit log only shows generic “rule edited” type entries and does not indicate:

• • When the Page condition lost its value, or

• • What specific field was changed.

• The customer reports that:

• • They configure the Page condition with the desired content status.

• • After some time, when they reopen the rule, the configured value has disappeared again and the same error message appears.

• • This is happening across many rules and spaces (100+ rules / 100+ spaces) on their site, not just on a single rule.

• As a result, scheduled rules that depend on these Page conditions may silently stop matching pages as expected, with no clear product-side indication beyond the broken condition UI.

Workaround

• There is currently no reliable, product-side way for the customer to guarantee that a status-based Page condition will permanently retain its value once set.

• Partial mitigations the customer can consider for their most critical rules:

1. 1. Use label-based conditions instead of status-based conditions

• • • Add/apply a dedicated label (por ejemplo, expired-needs-review) to pages that should be targeted by the rule.

• • • Change the Page condition to filter on that label instead of the content status.

• • • Label-based conditions do not appear to be affected by this specific behavior.

1. 1. Add notifications to detect when rules stop running as expected

• • • Add an email or chat notification action at the end of each key rule, including a summary of how many pages it processed.

• • • If a run is expected and no notification is received, this gives admins a signal to check whether the Page condition has broken again.

• However, these workarounds:

• • Do not prevent a status-based Page condition from losing its value again, and

• • Require non-trivial reconfiguration effort for customers who already have many rules (100+ in this case).