Drupal ECA automation and business rules

Why teams move Drupal automation into ECA models

Teams that maintain approvals, notifications and field updates in custom hook code or inherited Rules configuration usually have the same problem: the logic that decides what happens to content is spread across PHP files and contributed module settings that few people can read end to end. ECA models make that logic visible and editable as configuration. Each model is built from an event that starts it, conditions that decide whether it runs, and actions that change data or send messages, so a reviewer can follow an approval path on one screen and an editor with the right permissions can adjust it without a code release.

ECA fits three situations well. The first is new automation, such as notifying a review group when content enters a moderation state or updating a related entity after a save. The second is replacing Rules, which the ECA project positions as its successor for site builders. The third is upgrading an existing ECA 2 site, where the modeling layer changed: according to the ECA project page, ECA 3 moved modeling into the Modeler API and removed the ECA 2 eca_modeller_bpmn sub-module, so models and any sub-module references need a deliberate migration plan. Confirm the current ECA 3 release notes before you commit to a sequence. ECA 3.1.9 requires Drupal ^11.3 or ^12.0, so a site still on Drupal 10 or an earlier 11.x minor must first move its core version, which becomes a separate upgrade with its own test cycle.

ECA is not the right tool for every rule. Logic that is long, performance-sensitive, heavily branched or reused by several modules is usually clearer as a tested custom module, and a model that grows into dozens of nested branches becomes hard to review. Ask who will own each model after launch, which roles may edit it, and whether changes will pass through the same code review and staging path as other configuration. Those answers decide whether ECA reduces maintenance or simply moves it into a less visible place.

What ECA models do in a Drupal site

An ECA model connects an event to optional conditions and then to actions, so each automation can be read, reviewed and changed as one unit. The cards below cover the parts of that structure, the Modeler API in ECA 3, and how models touch entities, users and content moderation.

Events start every model

An event is the trigger that starts a model, such as an entity being saved, a user logging in or a form being submitted. Each model begins with one event, so the first design decision is which change in the site should start the work. Confirm the exact event plugins available for your Drupal version, because the list depends on which contributed modules are installed. Test each event with a realistic save path, including bulk imports and API writes, since not every path fires the same events.

Conditions decide whether actions run

Conditions are checks that must pass before the actions in a model run, for example a field value, a user role or the bundle of a content entity. Keep conditions explicit and short so a reviewer can trace why an action fired or did not fire. Confirm which condition plugins exist for your version and which need extra modules. Document any condition that depends on data outside Drupal, because that check will behave differently when the external system is slow or unavailable.

Actions change entities and send work out

Actions do the work: they set field values, create or update entities, send email, or call other services. Each action is a plugin, so a model is only as safe as the actions it uses and the permissions of the account that runs them. Ask which actions your team will need, then check each one for side effects such as repeated saves that trigger other models. Confirm the action list for your installed ECA version before you commit to a design.

The Modeler API in ECA 3

ECA 3 moved modeling into the Modeler API and removed the ECA 2 eca_modeller_bpmn sub-module. Teams that built models in ECA 2 need to plan how those models are exported, converted and retested against the new modeler before they upgrade. Check the ECA 3 release notes and the Drupal.org project page for the current compatibility requirements, including the Drupal versions the release supports.

Models acting on users and roles

Models often act on user accounts, for example assigning a role after a form submission or disabling an account when a record changes in an external system. These actions carry access control consequences, so the account that runs the model and the roles it can grant need a written review. Confirm which user actions your version provides and test each one against your role model before the model reaches production.

Interaction with content moderation

Models can react to transitions in Content Moderation, such as a move to a published state, and can also make changes that bypass the review step if they save content directly. Decide which transitions a model may trigger and which must stay with an editor. Confirm how the events and actions for moderation behave with your workflow setup, and test a draft, a review and a publish path separately.

Which ECA configuration decisions shape the build

The table compares the four configuration decisions a team must settle before building ECA automation: model granularity, where logic runs, error handling and who may edit models. Read each row as a choice with a trade-off, and settle the first two before any model is built, since they are costly to reverse.

Decision	Option	When it fits	Trade-off it creates
Model granularity	One model per business process	Multi-step flows such as order approval or content review, where the sequence matters to the business	Models grow large and are harder to read, and a change to one step can affect several flows
Model granularity	One model per entity or event type	Repeated reactions to the same event, such as sending a notice on every save of a content type	Logic for one business process gets split across several models, so reviewers must trace it across files
Where logic runs	ECA model with core actions and conditions	Simple field updates, notifications, role changes and reactions that a site builder can review visually	Complex calculations and loops are harder to test and debug in a visual model than in code
Where logic runs	Custom module with a plugin or service	Logic that needs unit tests, external API clients, or reuse across several ECA models and other code paths	Requires developer time for each change and a release cycle, which lowers how often business users can adjust rules
Error and retry handling	Fail the whole action and log it	Operations where a partial result is worse than no result, such as a financial status change	Users or editors may need to repeat the action manually, so the team must watch logs for failures
Error and retry handling	Retry from a queue with a defined limit	Calls to external systems, such as a CRM or payment service, that can fail temporarily	Retries can duplicate effects unless the target system accepts idempotent requests, so confirm this with each integration owner
Editing rights in production	Edits only through configuration deployment	Regulated sites where every automation change needs review, testing and an audit trail	Business owners cannot fix a rule quickly, so a release path must exist for urgent changes
Editing rights in production	Scoped editing by trusted site builders	Teams where business owners adjust low-risk rules often and an administrator reviews changes afterward	Production models can drift from the exported configuration unless the team reconciles them regularly

How an ECA build runs from inventory to handover

The sequence moves from finding what automation already exists to a documented, version-controlled set of ECA models that the client's team can maintain. Each step closes with a named output so the client can check progress before the next step begins.

Inventory existing hooks and Rules configuration
Begin by listing every custom hook implementation, Rules component, Rules reaction and scheduled job that changes content, users or data. Record the trigger, the conditions, the side effects and the owner of each item, and flag anything that depends on contributed modules that may not have an ECA equivalent. The output is an automation register with one row per behavior, marked as keep as ECA model, keep as code, or retire. The step is done when the client's business owners have signed off on each row.
Confirm the Drupal and PHP version target
Decide which Drupal core line the site will run and check that the ECA release you plan to use supports it. ECA 3.1.9 requires Drupal ^11.3 or ^12.0, so a site still on an older core needs a core upgrade before ECA 3 can be installed. Confirm the PHP version against the Drupal requirements, since Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. The output is a written version matrix covering Drupal core, PHP, ECA, and every contributed module the models depend on.
Prepare a non-production environment
Build a staging copy of the production site from the same codebase and a recent database snapshot, with the target versions installed. Install ECA and the Modeler API, and confirm that Rules or ECA 2 models from the inventory do not run on this copy until they are rebuilt. The team should be able to deploy the same codebase to staging and production without manual steps. The output is a working staging environment that matches production in code and configuration, with the differences documented.
Model the first processes in staging
Build the highest-value processes from the register as ECA models, starting with one event, a small set of conditions and a limited set of actions per model. Use the Modeler API in ECA 3 to draw each model and keep the labels and descriptions meaningful for the editors who will read them later. Where an ECA 2 model already exists, rebuild it in ECA 3 rather than expecting a direct import, and record every change in the register. The output is a set of named, reviewable models, each tied to a row in the register.
Test conditions and actions with real cases
Test each model against a defined set of cases, including the normal path, the boundary conditions and the cases that should not trigger the automation. Check that each action produces the expected change in content, users or integrations, and that errors leave the data in a known state. Re-run the test set after each change to a model. The output is a test log per model listing the cases, the expected results and the observed results, with failures resolved or accepted by the business owner.
Export configuration and review it
Export the site configuration, including ECA models, so that the models are stored in the codebase and not only in the database. Review the exported files for hard-coded environment values, such as URLs, credentials or user IDs, and move those values into settings or environment-specific configuration. Store the exports in version control with a review step before merge. The output is a versioned configuration set that deploys to staging and production through the same release process as the rest of the site.
Deploy and verify in production
Deploy the configuration through the normal release path, then confirm that each model is enabled in production only where the register says it should be. Trigger the events in a controlled way, check the resulting changes, and confirm that logs show the expected entries. Keep a rollback plan that disables the affected models without reverting unrelated changes. The output is a production verification record that lists each model, its status and the checks performed.
Hand over with a model catalogue
Write a model catalogue that lists every ECA model with its purpose, triggering event, owner, dependencies, test cases and last review date. Walk the client's administrators and editors through the catalogue and the process for requesting changes, including how upgrades of ECA and Drupal core will be tested against the models. The output is the catalogue, a change process document and a recorded handover session, which together let the client's team maintain the automation without the original builders.

Upgrading from ECA 2 or moving from Rules by situation

Sites on ECA 2 need the most careful move because the modeling layer changes. In ECA 3, modeling moves into the Modeler API and the eca_modeller_bpmn sub-module has been removed, so the site cannot keep its ECA 2 modeller and simply update the module. Treat the move as a rebuild of the model layer, with the logic of each model preserved and checked.

Inventory every model: Export each ECA model's configuration and record its events, conditions, actions and the content types, users or cron jobs that trigger it.
Redraw models in the Modeler API: Plan to rebuild each model in the ECA 3 modeler and compare it step by step with the ECA 2 original, since the conversion path should be confirmed for your versions.
Update custom plugins: Custom PHP actions or conditions written against ECA 2 may need changes to match the ECA 3 plugin interfaces. Confirm those interfaces in the ECA project documentation.
Version the old configuration: Keep the ECA 2 configuration in version control so outputs can be compared and the change can be rolled back.

Test each trigger in staging with representative content, including error paths and cron-driven models. Confirm that every model fires once and that none has been silently disabled by the module update.

What drives ECA effort and how to keep it down

This table lists the main factors that raise effort on an ECA automation project, why each one matters, and how to keep it under control. Read it before scoping, because most overruns come from unbounded process counts, custom actions written where a contributed action would do, and Rules logic copied over without review. The main takeaway is that agreeing scope and acceptance tests before the build is the cheapest lever available.

Driver	Why it raises effort	How to keep it down
Number of processes	Each model needs its own events, conditions, actions, testing and ownership. Effort grows with every process added to the first release.	Inventory all candidate processes, rank them by business value, and limit the first release to a small set with named owners.
Custom actions	Every custom plugin needs code, review, tests and an upgrade path across Drupal major versions such as 11 to 12.	Check contributed modules and core actions first. Build a custom action only when no existing action fits the requirement.
External API integrations	Authentication, rate limits, error handling, retries and vendor API changes add work on both the Drupal and third-party sides.	Confirm API access, sandbox availability and ownership before scoping. Keep each integration in a single reusable action with logged errors.
Rebuilding Rules logic by hand	Old Rules components rarely map one to one onto ECA events and conditions, so each one is re-read, redesigned and retested.	Document each existing Rules component's intended outcome, then model the outcome in ECA rather than translating the mechanics line by line.
Test coverage	Automation runs without a user present, so defects surface as bad data or missed notifications. Missing tests push effort into support and rework.	Agree acceptance tests for each process before the build, covering the success path, failure paths and data edge cases.
Model scope and complexity	Large models with many branches and nested conditions are harder to read, debug and change safely.	Split large workflows into smaller models with clear triggers, and review model size as part of each change.
Configuration management	Models that are not exported and reviewed in version control are hard to promote between environments and to restore after an incident.	Export ECA models into configuration management from the start and treat them as code under the same review process.
Upgrade path	ECA 2 models must be moved to the ECA 3 Modeler API, and the eca_modeller_bpmn sub-module was removed in ECA 3, so each model needs a check.	Inventory ECA 2 models before upgrading, confirm the target Drupal version supported by the chosen ECA release, and test each model after the move.

How ECA connects to the rest of the platform

An ECA model rarely stands alone. It reads and writes content states, users, roles, login sessions and external services, and each of those connections changes how the model behaves under load and during upgrades. The cards below name the integration need and the question to settle with your own environment before the model goes live.

Content moderation and workflow states

ECA models often react to a content transition, such as moving an article from draft to published, and then notify reviewers or update fields. Confirm which moderation workflow owns each state and whether automated actions should run on every revision or only on the default revision. Workspaces and scheduled publishing can fire the same events at unexpected moments, so test each path with the modules you actually run.

Users, roles and account changes

Actions that assign roles, block accounts or change profile fields carry access consequences. Decide which principal runs each action, because an action executed as an anonymous or administrator context can bypass the checks an editor would face. Confirm who approves changes to role-granting models and whether those models are reviewed like code.

Single sign-on account creation

When users arrive through the OpenID Connect or SAML Authentication modules, accounts may be created on first sign-in. An ECA model reacting to user creation can then assign roles or send welcome messages to people who were never reviewed. Confirm which identity attributes map to roles, whether the identity provider or Drupal is the source of truth, and how deprovisioning removes access.

CRM and webhook calls

Outbound HTTP calls to a CRM or webhook receiver are the most common reason an automation fails in production. Confirm the expected response codes, timeouts, and what happens when the receiving system is down. Decide whether a failed call should retry, alert a person or leave a record for later review, and make sure credentials are stored outside exported configuration.

Queues and cron for longer actions

Actions that call slow services, process many entities or generate files should not block a page request. Decide which steps go to a queue and which must complete in the request, and confirm how often cron runs on your hosting platform. Check that queued items are monitored, so a stalled worker does not leave records half processed without anyone noticing.

Configuration and environment drift

ECA models are stored as configuration, so they move between environments with the rest of the site. Confirm which models are exported, which environment-specific values such as endpoints and secrets are excluded, and who reviews changes before deployment. Without that boundary, a model tested on staging can point at production systems.

Keeping ECA models under configuration management

The core rule for this section is that every ECA model should reach production through the same Git and deployment path as the rest of the site, never by editing it in the production admin interface. ECA models are Drupal configuration, so a model built in a development environment is exported as configuration files, committed to the repository, reviewed, and then imported into staging and production with drush config:import or your deployment tooling. Confirm with your team which configuration sync directory and import step your pipeline uses, and check that the ECA configuration entities are included in the export. Treat the production admin UI as read-only for automation, and restrict the permissions that allow editing models there, so an urgent fix still goes through a commit.

Model review needs the same discipline as code review. A diff of exported YAML is hard to read, so reviewers should agree on a checklist: which event starts the model, which conditions guard each action, which actions write data or send messages, and which roles can trigger it. Pay particular attention to actions that call external services, change user accounts or publish content, because a mistake there is visible to users immediately. Keep one model per business rule where practical, so a change to one rule produces a small, reviewable diff. Record in the commit message why the rule changed, since the model itself shows what it does but not the business reason.

Environment-specific values such as API endpoints, mail recipients, queue names, roles and entity IDs should not be hard-coded into models that move between environments. Move them into settings, environment variables or Drupal's state and configuration overrides where the platform supports it, and verify each reference after import. Drift is the main long-term risk: a model edited in production, a configuration import skipped during a release, or a module update that changes an action's behavior can leave the code, the exported configuration and the live site disagreeing. Schedule a periodic comparison of the active configuration against the repository, and ask your implementation partner to document the drift check and who is responsible for resolving it.

Questions teams ask before hiring help with ECA

How much does an ECA automation project cost?

Cost follows from the written scope, not from a fixed rate, so DeployOpen does not publish prices. The main drivers are the number of models, how many events and external systems each model touches, how much business logic has to be agreed before building, and whether existing Rules configuration must be converted. Ongoing costs usually cover testing after Drupal core and ECA updates and any changes to business rules. When requesting a quote, ask for the work split into discovery, model build, testing, configuration export, handover and any retainer for later changes, with each item tied to a named model or integration.

How long does it take to move automation from custom code to ECA?

Duration depends on how many custom hooks, Rules components or scheduled tasks are in scope and how well their behavior is documented. Teams with a short list of well-understood automations usually finish faster than teams whose logic lives in undocumented custom modules. Confirm the target Drupal version first, because ECA 3.1.9 requires Drupal ^11.3 or ^12.0 according to its Drupal.org project page. Ask any provider for a timeline that separates inventory, parallel running and cutover, since those phases often take longer than the build itself.

What do we need from our developers and business owners?

Developers need to provide the codebase, a working development environment, access to the systems each model calls and a way to deploy configuration to test and production. Business owners need to state the rules in plain language, name the people who approve exceptions and confirm expected outcomes with real examples. Without those decisions, models get rebuilt during testing. Agree on a single owner for each automation who can answer questions within the project window.

Can an internal team build ECA models without outside help?

Yes, a team with Drupal administration skills can build simple ECA models using the Modeler API in ECA 3, which replaced the ECA 2 eca_modeller_bpmn sub-module. The harder parts are event design, error handling, permissions for the user running actions and testing across content states. Teams usually need outside help when models touch several integrations, must be audited, or must run unattended on production data. Assess your own skills against a small pilot model before deciding how much to hand over.

How much effort does migrating from Rules to ECA take?

Effort scales with the number of Rules components, the custom actions they call and the number of site-specific conditions. Rules reactions that map to a single event and a few actions are typically straightforward to recreate. Components that rely on custom PHP, nested logic or undocumented side effects need analysis before any model is drawn. Start with an inventory that lists each Rules component, its trigger, the entities it changes and who depends on it. Plan a period where old and new automations run side by side, and confirm the migration path for your specific ECA version in the ECA project documentation.

How does the Drupal 12 timing affect our ECA plan?

Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Because ECA 3.1.9 requires Drupal ^11.3 or ^12.0, any site still on Drupal 10 will need a core upgrade before it can take the current ECA release. Build the automation inventory now so the upgrade and the ECA work can share one test plan. Ask your provider how they will verify models against the target core and PHP versions, since Drupal 12 requires PHP 8.5 or later according to the Drupal PHP requirements page.

How do we keep ECA models under configuration management?

ECA models are stored as configuration, so they can be exported, reviewed and deployed like other site settings. Keep the exported configuration in version control, require review for changes, and deploy through the same pipeline as code. Establish who may edit models in production and whether that is permitted at all. Ask the provider to document the export and import steps, the test environment used for each change, and how a rollback is performed. Confirm the approach with your own deployment setup before committing to it.

Who is responsible for security when automation runs on the site?

Every ECA action runs with permissions tied to the account or context that triggered it, so the security review must cover those accounts, the external credentials each action uses and the data each model can read or change. Store secrets outside exported configuration, limit actions that delete or publish content, and log model executions for audit. Include ECA models in your regular security testing scope so changes are reviewed the same way as custom code. Confirm with your security team which audit trail you need before the first model goes live.

How DeployOpen scopes and delivers Drupal ECA automation

DeployOpen plans, builds, documents and supports Drupal ECA automation inside your own infrastructure, from the first business rule to the configuration that ships it. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the manual steps, notifications and rules you want automated, and sort them by event, condition and action.
Confirm the Drupal core and ECA versions in use, since ECA 3.1.9 requires Drupal ^11.3 or ^12.0.
Write the scope with named models, deliverables, test cases and exclusions before any build starts.

How we build

Model each automation in the Modeler API, keeping events, conditions and actions visible to your team.
Move logic that outgrows a model into a small custom module, so the model stays readable for editors.
Test each model on a staging site with representative content, roles and failure cases before release.

How we hand over

Export ECA models and related configuration into your repository so changes go through the same review as code.
Document each model with its trigger, conditions, owner and the process it supports.
Walk your administrators through editing, disabling and rolling back models in a session your team can repeat.

How we support

Plan ECA upgrades alongside Drupal core releases, which follow a fixed monthly and security release cadence.
Offer ongoing support, upgrades and testing as a retainer after handover, scoped in writing.
Confirm with your team who owns each model after launch, so changes to business rules have a clear approver.

Drupal ECA for no-code automation and business rules