ECA is a powerful module. Perhaps even too powerful for its own good — depending on the context in which you use it.
What is ECA?
ECA (Event-Condition-Action) is one of the most mature no-code tools in the Drupal ecosystem. Its principle is straightforward: react to events, evaluate conditions, trigger actions. In practice, this allows it to intervene across a wide range of Drupal behaviours — without writing a single line of code.
Historically built on bpmn.io for its modelling interface, ECA has recently evolved with the arrival of the modeler module, developed in ReactJS by its main contributor Jürgen Haas. This new interface notably introduces the ability to visualise and replay workflow execution — a welcome improvement.
But a better interface isn't enough to erase the module's conceptual difficulties. The question remains: should it be used on every project?
Why it's not always a good idea
Before listing the arguments, let's set the context: ECA is not a bad tool. What follows is a list of situations where it becomes a bottleneck rather than a lever.
A real learning curve — even for developers: ECA uses tokens to pass and reuse data between its components. This mechanism, unavoidable as soon as you're handling data, requires genuine time to internalise. Unlike PHP code where logic is explicit, ECA relies on a fundamentally different mental model — and one that's poorly documented beyond simple use cases.
A default abstraction level that's too low: The events and actions ECA provides natively are very granular. That's a strength for flexibility, but also a problem: to use them correctly, you need to understand Drupal's internal concepts (entities, hooks, form lifecycle…). ECA doesn't simplify Drupal — it exposes it.
Added complexity on projects with custom development: When a project mixes custom code and ECA rules, overall readability suffers. It becomes hard to know "who does what": is it a custom hook? An event subscriber? An ECA rule? This dispersion of application behaviour increases maintenance costs and complicates onboarding.
Configuration conflicts that are hard to manage: ECA configuration is versioned — in XML with bpmn.io, in YAML with modeler (a notable improvement). But in a standard git workflow, merge requests on these files remain tricky. Diffs are hard to read, conflicts are complex to resolve, and code review loses its effectiveness.
Functional tests only — no unit testing: You can't write unit tests for ECA rules. Only functional tests are viable, which increases execution times and limits the coverage achievable compared to standard code.
Adding development to avoid development: If ECA doesn't natively cover your need, you'll have to either bend it to fit, or build your own ECA plugins. The result: you write code to avoid writing code. The equation no longer holds.
A deployment pipeline that can wipe your configurations: If your deployment workflow automatically imports configuration files, any change made directly in production — by you or your client — will be overwritten on the next deploy. You have to plan ahead by explicitly excluding ECA configs from the import, which adds an operational layer of complexity.
No native filtering of available events: If you give a non-technical user access to the ECA interface, they have access to every available event and action — including the most dangerous ones. There is no native mechanism to restrict this list.
Lower performance than dedicated code: Running an ECA workflow involves loading and traversing the entire rules engine. For any given feature, targeted PHP code will consistently outperform it.
A real-world example. While testing Drupal CMS, I noticed that a natively supported Drupal feature had stopped working: the register_no_approval_required email sent when a new user account is created. After investigation, the culprit was an ECA rule introduced by a Drupal CMS recipe — one that silently overrode Drupal's default behaviour. The result: regardless of the configuration, every account creation triggered the same email: "An administrator has created an account for you." This kind of bug is particularly insidious to diagnose, precisely because nothing in the code reveals the existence of the rule.
And yet, we use it at IOSAN
Yes. And we'll keep doing so. ECA remains a remarkable module — as long as you know why you're using it. At IOSAN, we actively contribute to its ecosystem:
- ECA Breadcrumbs — manage dynamic breadcrumbs via ECA
- ECA Expression Language — use expression language in ECA conditions
This isn't a contradiction: knowing a tool's limits is precisely what allows you to use it intelligently.
So, should you use it?
The real question isn't "should we use ECA?" but "in what context, and for whom?"
When it makes sense
- You want to give autonomy to a client, webmaster, or non-technical editor
- The feature is clearly scoped, low in complexity, and its entire logic will live in ECA
- You want the rule to be able to evolve directly in production.
When to avoid it
- You're a developer trying to avoid writing code you're perfectly capable of writing
- The project is substantial, with parallel custom development
- You need reliable tests, optimal performance, or easily auditable code
- You use AI to generate or maintain code — ECA's YAML/XML files are far less usable than PHP
A note on AI. As development assistance tools become mainstream, it's worth noting that LLMs understand and generate PHP far more effectively than ECA's YAML or XML configuration. If AI is part of your development workflow, this is a factor worth weighing.
Conclusion
ECA's main selling point is the autonomy it gives to non-developers. If you want your client to manage their own business rules without depending on a developer, this is the right tool for the job.
As a developer, ECA only makes sense within a narrow scope: well-defined, low-complexity features whose logic lives entirely in ECA — and where evolving rules directly in production is acceptable.
Outside that scope, trust your skills. Code remains, today more than ever, the most readable, testable, and maintainable approach for serious projects.
As we said, ECA is a remarkable module. And beyond its technical use cases, it plays a much bigger role: it radically transforms Drupal. Combined with Drupal CMS — with its Marketplace, Recipes, and Module Installer — it makes it a highly accessible solution, without sacrificing stability, feature richness, or the open-source ethos. Drupal stands its ground against Wix, Squarespace, Weebly, Jimdo, Shopify, and BigCommerce. A serious, sustainable, and uncompromising choice.
