Skip to main content
← All articles
drupal

No-code automation is still code: ECA, the dead Rules module, and reviewable workflows

No-code automation is still code: ECA, the dead Rules module, and reviewable workflows

For years the standard Drupal advice was "the Rules module is stuck, use ECA instead." I repeated it myself. So while writing this I checked, and the tidy story is out of date: Rules shipped a stable 4.0.1 in February 2026 with proper Drupal 10.3+ and 11 support. It's not dead. It's just already lost — and looking at why it lost, and what won, says something honest about "no-code" automation that the marketing skips.

What actually happened to Rules

Rules didn't fail on its merits; it failed on its timeline. It spent the entire Drupal 8/9/10 era stuck in alpha and beta — years where anyone starting a modern site needed automation and Rules couldn't promise a stable release. That vacuum is exactly what ECA (Event-Condition-Action) was created to fill in 2021, and by the time Rules reached a stable 4.0 in 2026 the race was over. Rules still reports ~79,000 sites (mostly legacy), ECA around ~18,000 and climbing — and crucially, ECA is where the momentum and the new builds are. "Recovered but overtaken" is the fair summary.

What ECA is, honestly

ECA is a visual automation framework: an event fires (node presave, user login, form submit), conditions gate it, actions run — and the actions largely reuse Drupal core's own Action plugins. It's architected on top of core's event and action systems rather than a bespoke engine, which is a big part of why it's more maintainable than Rules was: it rides core instead of fighting it. The editing UI is a separate concern — ECA itself is just the processor, and you pick a modeler (the BPMN.io graph editor, a newer React-Flow drag-and-drop one, or a plain form-based one). Models are stored as ordinary config entities — one YAML file per model, exportable with Drush and committable to Git.

The "no-code is still code" part

Here's the thing the demos gloss over, and it's the reason I still reach for PHP more often than not. "It's in config, so it's version-controlled!" is true in the most useless sense. Yes, an ECA model is a YAML file in Git. But open the diff after you tweak a workflow and you get a churned blob of reordered node IDs, BPMN canvas coordinates, plugin machine names, and token strings. It is version-controlled. It is not version-reviewable. A colleague reviewing that PR cannot see intent; they see a serialized graph. You've satisfied the letter of code review while defeating its purpose.

A visual workflow you can't read in a diff, can't set a breakpoint in, and can't unit-test isn't "no-code." It's code written in a format optimised for the author and hostile to everyone who comes after.

And it rots the way all visual logic rots: fine for "when a node is published, email the editor," miserable once you've got nested conditions, loops, and computed values expressed as boxes and arrows. The failure mode isn't that ECA is bad — it's that a graph editor makes complexity easy to add and hard to see.

Where I draw the line

I'm not anti-ECA; that would be silly. The honest dividing line, for me:

  • Reach for ECA when the logic genuinely is "event → condition → action," when a site builder without PHP needs to own it, when the change must ship without a code deploy, or when you're prototyping. That's a large, real class of work, and ECA does it without a custom module.
  • Reach for a custom event subscriber the moment the logic has loops or real computation, needs to be unit-tested, integrates with an external system, or is complex enough that a future reviewer needs to read it. A 30-line EventSubscriber class is a readable diff, a breakpoint, and a test. An ECA model is none of those.

To be clear, this is my synthesis, not a settled community verdict — plenty of shops run heavy ECA happily. But the "no-code" label quietly promises you've escaped the responsibilities of code, and you haven't. You've just moved them somewhere your tests and your reviewers can't follow. Rules taught the community a lesson about maintenance; ECA is teaching a subtler one about reviewability. Both are worth learning before you wire your whole site together with boxes and arrows.

Links

BM
Blue Moose
The moose behind Blue Moose. Full-stack PHP developer — Drupal by day, Symfony by night, tests always.