Governance · 12 / 23
Content alarms
Filter a collection down to what looks wrong, save it as an alarm, and every match is flagged — nothing is ever blocked.
Rules that watch this workspace’s content. They flag problems; they never block a save or a publish.
- Errors
- 2
- Warnings
- 416
- Info
- 0
- Last checked
- 6 min. agothis minute
248 records in this collection.
The CMS will keep checking Articles against this filter and flag whatever matches. It never blocks a save or a publish.
Matches now: 12 of 248
How it works
- 01
Filter a content list down to the records that look wrong.
- 02
Save it as an alarm, at Error, Warning or Info.
- 03
Matches are flagged on the Alarms page and on the record itself.
- Levels
- Error, Warning, Info
- Blocking
- Never
- Re-checked
- On every change, and hourly
In depth · For whoever owns the state of the content
Rules that flag, never block
Turn the list of things that keep going wrong — a live article with a draft author, a product with no image — into rules the CMS checks for you.
A rule is a saved list filter
Narrow the records list until it shows the problem, then save that filter as a rule with a severity. There is no second query language: the rule runs through the same code as the list, so the two always agree.
Under the hood
Every finding links back into the records list showing exactly what it matched, so you can go and fix them.
A filter narrowing a records list to fourteen of 1,046 records, saved as a named rule with a severity, producing fourteen findings that update as content changes.
No severity can block
Info, Warning and Error differ only in how loud they are. An alarm never blocks a save or a publish. What must not ship belongs in the content type’s validation; everything else worth flagging belongs here.
When a rule is checked
| When | What it covers |
|---|---|
| On every change | Saves, publishes, deletes and restores re-check affected rules. |
| On demand | Creating or editing a rule rescans immediately. |
| On a timer | An hourly sweep catches content nobody is touching. |
Built to be trusted
- Findings close themselves
- Publishing a draft author re-checks the entries that point at them.
- A broken rule says so
- If a field is renamed under a filter, the rule is marked broken, not silently empty.
- History survives a fix
- A finding that reopens keeps the date it was first seen.
- Editors see them, admins write them
- Findings show inline in the entry editor; writing rules is admin-only.
- The assistant can read them
- Ask “what is wrong with this workspace right now” in the chat.
Questions
Can I make one that blocks publishing?
No. Put that condition in the content type’s validation, where the publish gate enforces it.
Will it email me?
Not by itself. Findings live in the admin and on the findings endpoint, which is what to poll if you need to be told.
What does it cost on a big library?
Changes check only the rows that changed. The hourly sweep has ceilings, all of them plugin settings.