DEV Community: Neharika Mohan

ECA vs Rules vs Custom Code: The 2-Minute Decision Guide

Neharika Mohan — Wed, 13 May 2026 10:16:39 +0000

One of the most common Drupal architecture questions is: should this workflow live in ECA or custom code?

The answer depends on your project version, workflow complexity, and team capabilities. This guide provides a practical decision framework.

Current State of Each Option

Rules

Widely used in Drupal 7 with mature ecosystem
Available for Drupal 8+ but still in development
For greenfield Drupal 10/11 projects, ECA generally has stronger ecosystem momentum

ECA (Event-Condition-Action)

Built specifically for Drupal 8+ architecture
Uses modern Drupal APIs (Typed Data, Plugin system)
Provides visual workflow modeling with BPMN
Actively developed with regular releases

Note on ECA limitations: Visual workflows become harder to maintain once business logic becomes deeply nested or computation-heavy.

Custom Code

Traditional PHP module development
Full control over implementation
Direct access to Drupal APIs
Better suited for complex algorithms

Decision Matrix

Your Scenario	Recommended Approach
Drupal 7 project	Rules
Drupal 8+ automation	ECA
Complex calculations	Custom Code
Custom entity types	Custom Code
Reusable libraries	Custom Code
Long-running tasks	Custom Code + Queue API

When to Use ECA

ECA works well for:

Event-driven workflows:

User registration actions
Content publishing workflows
Form submissions
Scheduled tasks via cron

Conditional logic:

Role-based field visibility
Content type specific actions
Value-based triggers

Form alterations:

Dynamic field visibility
Conditional validation
Field option modifications

Content automation:

Publishing workflows
Content moderation
Automated notifications

Team considerations:

Site builders need to maintain workflows
Visual documentation is valuable
Configuration management preferred

When to Use Custom Code

Custom code is better for:

Complex business logic:

Multi-step calculations
Integration with external APIs
Data processing pipelines
Algorithm implementation

Performance requirements:

High-volume operations
Time-sensitive processing
Resource-intensive tasks

Async processing:

For long-running or API-heavy tasks, consider combining ECA triggers with Queue API workers
Background jobs via cron
Batch operations

Reusability:

Shared across multiple projects
Custom field types or widgets
API clients

Custom functionality:

New entity types
Custom database schemas
Core behavior modifications

When to Use Rules

Rules makes sense for:

Drupal 7 projects where it's already working
Teams familiar with Rules D7 patterns
Projects not planning to upgrade soon

For Drupal 8+ projects:

ECA provides better integration with modern Drupal APIs
Consider ECA for new implementations
For greenfield Drupal 10/11 projects, ECA generally has stronger ecosystem momentum

Practical Examples

Example 1: Welcome Email

Scenario: Send email when user registers

ECA approach:

Configure in UI
Site builders can modify text
No code deployment needed

Custom code approach:

Write hook implementation
Requires developer for changes
Standard code deployment

Best choice: ECA for this scenario

Example 2: Shipping Calculator

Scenario: Calculate shipping costs based on weight, destination, carrier rates, promotions

ECA approach:

Possible but complex to maintain
Many connected actions needed
Visual workflows become harder to maintain with deeply nested logic

Custom code approach:

Clean service class
Unit testable
Better for complex calculations

Best choice: Custom code for this scenario

Example 3: Content Publishing Workflow

Scenario: Auto-publish when review status changes to approved

ECA approach:

Visual workflow diagram
Easy to understand and modify
Self-documenting

Custom code approach:

Event subscriber pattern
Less visible to non-developers

Best choice: ECA for this scenario

Example 4: API Integration with Long Processing

Scenario: Sync data with external system, processing takes 30+ seconds

Hybrid approach:

ECA triggers the workflow on content save
Custom Queue API worker handles the actual processing
Prevents timeouts and blocking requests

Best choice: ECA trigger + Custom Queue worker

The Hybrid Approach

Most projects benefit from using both:

Example project structure:

your_project/
├── config/
│   └── eca/
│       ├── user_registration.yml
│       ├── content_moderation.yml
│       └── form_validation.yml
├── custom_modules/
│   ├── your_shipping/
│   ├── your_payments/
│   ├── your_api_client/
│   └── your_queue_workers/

Use ECA for:

User workflows
Content automation
Form behaviors
Email notifications

Use custom code for:

Business logic
External integrations
Performance-critical paths
Queue workers for async processing
Reusable components

Making the Decision

Ask yourself these questions:

1. What's your Drupal version?

D7: Rules is fine
D8+: Consider ECA for new automation
D10/11: ECA has stronger ecosystem momentum

2. Can you describe it as "When X happens, if Y is true, do Z"?

Yes: ECA is likely a good fit
No: Might need custom code

3. How complex is the logic?

Simple conditions: ECA
Deeply nested logic: Custom code
Complex calculations: Custom code

4. Who needs to maintain it?

Site builders: ECA
Developers only: Either works

5. What are the performance requirements?

Standard: ECA works fine
High-volume or async: Custom code + Queue API

6. How long does it take to run?

Under 5 seconds: ECA is fine
Long-running: Custom code with Queue API

Migration Path

Moving from Rules to ECA:

Document existing Rules functionality
Prioritize which to migrate first
Build equivalent ECA models
Test thoroughly in development
Run both in parallel briefly
Switch to ECA when confident

Tips:

Token syntax may differ
Event names might not match exactly
Test with actual data

Common Use Cases

ECA is commonly used for:

Welcome emails and user onboarding
Content approval workflows
Notification systems
Form field show/hide logic
Auto-tagging content

Custom code is commonly used for:

Payment gateway integrations
Complex pricing logic
Third-party API clients
Queue workers for background processing
Custom reporting
Data transformation pipelines

Technical Considerations

ECA strengths:

Visual documentation
Configuration management
Site builder friendly
No deployment for changes

ECA limitations:

Visual workflows become difficult with deeply nested logic
Not ideal for computation-heavy tasks
Limited debugging compared to code

Custom code strengths:

Full control and flexibility
Better for complex algorithms
Unit testable
Better debugging tools

Custom code limitations:

Requires developer for changes
Code deployment needed
Less visible to non-developers

Choosing Your Path

For most Drupal 8+ automation needs: Start with ECA. It handles the majority of event-driven workflows well.

When logic gets complex: Move to custom code. Visual workflows become harder to maintain once business logic becomes deeply nested or computation-heavy.

For long-running operations: Combine ECA triggers with Queue API workers to handle async processing.

For Drupal 7: Rules continues to work well for its original use case.

Resources

ECA:

Rules:

Custom Development:

Final Takeaway

The best Drupal projects don't choose between ECA and custom code—they use each where it fits best.

Start with the simplest solution that meets your needs. ECA for straightforward workflows, custom code for complex logic, and hybrid approaches when combining both provides the best result.

What approach do you use for automation in your Drupal projects? Share your experience in the comments.

ECA vs Custom Modules in Drupal - When to Use Which

Neharika Mohan — Mon, 04 May 2026 13:03:40 +0000

If you've worked with Drupal long enough, you've faced this decision:
Do I build a custom module for this or can ECA handle it?
Here's a straight answer.

Use ECA When

The logic is workflow-based
Approvals, notifications, reminders, role assignments anything that follows an "if this then that" pattern is exactly what ECA is built for.
Non-developers need to maintain it ECA workflows live in the admin UI. Your client or site admin can read, modify, and debug them without touching code. A custom module cannot offer that.
Speed matters A workflow that would take a day to build as a custom module can be done in ECA in an hour. For agencies and freelancers, that margin is money.
You want reusability ECA configs export as YAML. Drop them into any Drupal project and they work. No copy pasting PHP across projects.

Use a Custom Module When

You need complex business logic Heavy data transformations, third-party API calls with custom authentication, or multi-step calculations are better handled in PHP where you have full control.
Performance is critical ECA adds overhead. For high-frequency operations like processing thousands of records a lean custom service will always outperform an ECA workflow.
You need testability Custom modules can be unit tested. ECA workflows currently cannot. If your team writes tests, custom code wins here.
ECA doesn't have the event or action you need ECA is extensible but not infinite. Sometimes the specific trigger or action you need simply doesn't exist yet and writing a custom module is the only option.

The Sweet Spot Use Both
This is what experienced Drupal developers actually do.
Write a custom ECA action or event in PHP, then wire it into an ECA workflow visually. You get the power of custom code with the flexibility of a visual workflow.
Example: Write a custom action that calculates a student's eligibility score in PHP then trigger it from an ECA workflow on form submission, send an email based on the result, and assign a role. Clean separation of concerns.

Quick Reference

Situation	Use
Email/notification workflows	ECA
Approval & review flows	ECA
Heavy data processing	Custom module

Bottom Line
ECA is not a replacement for custom modules it's a replacement for simple custom modules. Know the difference and you'll ship faster, write less throwaway code, and build systems that clients can actually maintain.
In the next post I'll show you how to write a custom ECA action in PHP and plug it into a workflow.

Follow so you don't miss it.

What is ECA in Drupal And Why You Should Know It

Neharika Mohan — Tue, 28 Apr 2026 16:13:28 +0000

If you've been building Drupal sites, you've probably written custom modules just to send an automated email or build a simple approval flow.
What if you didn't have to?
That's what ECA is for.

ECA = Events, Conditions, Actions
It's a Drupal module that lets you build automated workflows from the admin panel no custom PHP needed.
The mental model is simple:

When this happens → check this → do this

Real example:

Event: User submits a form
Condition: User role is "Student"
Action: Send a welcome email + assign them to a group

Zero code. Built visually in minutes.

Why Developers Love It

Visual interface — flowchart style, easy to debug and explain to clients
Covers most use cases — form submissions, entity changes, user login, scheduled triggers
Works with popular modules — Webform, Views, Token, Rules
Exportable — save workflows as config, reuse across projects

Quick Install

composer require drupal/eca drupal/bpmn_io
drush en eca eca_base eca_content eca_user eca_form eca_ui bpmn_io
drush cr

Then go to Configuration → ECA and you'll see the visual workflow builder.

Bottom Line
ECA replaces hours of custom module development with a visual, maintainable workflow anyone on your team can understand.

Have a workflow you're currently solving with custom code? Drop it in the comments might be the next tutorial.