Automations

1.7.12026-09-07

• Card changes cost the extension far less work than in 1.7.0. Every card or relation change in the instance was inspected in full — the card fetched, the metamodel loaded — before the extension could tell it had nothing to do; measured on a running Turbo EA at about fifteen database statements per change with no rule enabled, against one in 1.6.1. It now asks the cheap question first (is any rule triggered by this, is any rule holding this card) and only reads the card when the answer is yes. Nothing about what fires, or when an episode ends, has changed.
• A scan updates its rule once, not once per card. Every card a scan fired for rewrote the rule's «last run» line in turn, thousands of times for one scan, on the very table every card change then reads. It is written once at the end of the scan with the scan's outcome.

1.7.02026-09-07

• «Fire once per card» now means once per episode. A rule tells you when a card starts matching its conditions and then stays quiet until that card has stopped matching and matches again. Edit a broken card twice and its owner hears once; re-approve it and break it again and they hear about the new break. Before, the rule remembered the exact values it had read, which got both halves wrong: a card that broke, was re-approved and broke again read the same values and was never mentioned again, while a rule watching a threshold spoke up every time an unrelated field moved. Rules you already have need no change.

• «Approved card edited» no longer notifies on every later edit of a broken card. The template now fires on the edit that breaks the approval, which is what its description always promised. An installed copy is corrected when you upgrade — unless you had edited its conditions yourself, in which case yours are left alone and the change is recorded in the rule's history.
• A rule that only notifies now shows up in the Runs tab and on the card. Runs were only recorded for rules that changed something, so exactly the rules whose owners wanted proof that they had run — the ones that just send a notice or call a webhook — showed nothing on the card's automation chip and nothing in the log.
• The automation chip on a card lines up with other extensions' chips instead of claiming a line of its own (needs Turbo EA 2.132.2).

1.6.12026-09-06

• The «Quarterly data refresh» template now sits under Data quality in the templates gallery. It arrived in 1.6.0 filed under a section of its own, headed with an untranslated label and pushed below Integration, which made it easy to miss. It now appears alongside the other two data-quality templates. Nothing about the template itself changes, and a rule already created from it is unaffected.

1.6.02026-09-06

• A scheduled rule can send one survey instead of a todo per card. The new Send a survey action collects every card a run matched and sends its stakeholders one data-maintenance survey about the whole set: one notification per person, one response form per card with the fields you picked (each set to Update or Confirm), results reviewed and applied in Admin → Surveys like any survey. The Runs tab shows a Survey row with a link to the results, Simulate previews how many people and cards a survey would reach, and rolling the run back from the Audit Log closes the survey. Needs Turbo EA 2.132.1.
• New template «Quarterly data refresh»: on the first day of every quarter, the owners of every application that is not fully documented receive one survey to confirm the criticality and refresh the cost and hosting.

• The demo rule «Mission-critical application below the data-quality target» now sends a weekly survey to the technical owners instead of a nightly todo per card and a note to the business owner. Reload the demo data to pick the new shape up; a demo already loaded keeps its rules as they are.

1.5.12026-09-06

• A rule that only notifies people or calls a webhook no longer leaves an empty entry in the Audit Log. Every run used to open an audit batch before knowing whether it would write anything, so a notification-only rule left one entry per run with a Rollback button that reversed nothing. Such a rule now opens no batch at all — and a run whose writes all turned out to be already in place no longer links to an audit entry either.
• Rolling back a run now also removes the todos it created, as long as nobody has completed them. Needs Turbo EA 2.131.0; on an older core the todos are still reported as not reversible, as before.

1.5.02026-09-06

• The Rules and Runs tables remember how you set them up. Column widths, sort order, which columns are shown, their order and any you have frozen to the left all come back after a reload — on both tables, each keeping its own layout. The Runs tab also keeps the rule and state you last filtered by.
• Filter any column from its header. Every column on both tables now has a filter, so you can narrow to one card type, one trigger or one outcome without leaving the grid. Right-click a cell for Show matching and Filter out as well — those were in the menu before but had nothing to act on. Your column filters are remembered too.
• Choose the columns on the Runs tab. A Columns button beside the filters hides the columns you do not need and pins the ones you do, the same control the Rules tab has in its sidebar.
• Pause a rule from the right-click menu. Right-click any rule and choose Pause, or Enable on a paused one — the same immediate switch as the toggle in the table, without hunting for the column. A rule that still has problems to fix says so instead.

• Freezing a column and reordering columns now actually work. The pin in the Columns list and dragging a column header were both being recorded but never applied, so the layout reverted the moment the page redrew.
• The card-type filter in the Rules sidebar is remembered along with the other filters, instead of being dropped on every reload.
• The two tabs no longer overwrite each other's layout. Preferences are saved field by field, so setting up the Runs table can never revert what you did on the Rules table.

1.4.02026-09-05

• Assigning a stakeholder role from a rule now needs its own permission. A stakeholder role is not just a label: whoever receives it gains card-level permissions such as editing the card and managing its relations. Until this release, anyone who could configure automations could write a rule that assigned themselves a role across a whole card type, run it, and end up able to edit the landscape. The two role actions now require a new «Author rules that assign or remove a stakeholder role» permission (ext.automations.grant_roles) in addition to the existing manage permission. One-time step on upgrade: grant the new permission to any role that should keep authoring those two actions — Admin → Users & Roles. Rules you already have keep running on their schedule untouched; the permission is checked when a rule is created, edited, enabled or run by hand, so nothing stops working silently. People without it no longer see the two actions offered in the rule editor.

• Webhook deliveries are pinned to the address that was checked. The extension already refused to post to a private or internal address; it now connects to the exact address it checked rather than looking the name up a second time, which closes a window where a fast-changing DNS record could answer with a public address for the check and an internal one for the delivery. Certificates are still verified against the real host name.
• A webhook signing secret must be named webhook.…. The name comes from the rule, so without a prefix a rule author could point it at any credential this extension holds.
• The webhook host allow-list is documented as what it is: leaving it empty means «any public host», not «none» — the private-address refusal is what always applies.

1.3.02026-09-05

• Run now and Simulate show their progress. A run no longer blocks the page behind a spinner: the dialog shows how many cards were checked, matched and fired while it works, and a run keeps going if you close the dialog — its outcome is in the Runs tab.

1.2.02026-09-05

• A run is now one execution of a rule, not one card. The Runs KPI, the Failed tile and the demo caption count a schedule firing, a nightly catch-up, a Run now or an event delivery once, however many cards it acted on; the Runs tab still lists every card. Runs recorded before this version count as one execution each.
• Loading the demo data no longer runs the rules. It installs the templates and the three demo rules (most of them enabled) and returns at once; they then fire on their schedules and when cards change. Removing the demo data still deletes the rules and whatever they raised meanwhile.

• Loading the demo data could time out and flood your inbox. The seed used to scan the inventory with five rules inside the request, raising a todo or risk per matching card — each one a notification and email — and a proxied instance cut the request off (HTTP 524).

1.1.12026-09-05

• This extension now ships a changelog. Every release from here on documents what changed for you in this file, and it travels inside the signed bundle so it is on disk wherever the extension is installed.

1.1.02026-09-05

• Automations has its own notification type, with its own row in your notification preferences — so you can tune (or silence) what your rules send without touching every other extension notice.
• A digest opens its details in the app. A notification covering several cards now shows the full list in a dialog, with the buttons to open a card or the Automations page offered only to people allowed to go there.

1.0.02026-09-05

• First release. Governance rules built from dropdowns — when something happens, if a condition holds, then take an action. Rules run on events or on a schedule, can be simulated before they are switched on, and every run lands in Admin → Audit log as one batch that can be rolled back in one click. Ships with templates, demo data and a settings page in the Admin menu.