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

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:

1. Document existing Rules functionality
2. Prioritize which to migrate first
3. Build equivalent ECA models
4. Test thoroughly in development
5. Run both in parallel briefly
6. 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:

• ECA Module
• ECA Guide
• BPMN.io Modeler

Rules:

• Rules Module
• Rules Documentation

Custom Development:

• Plugin API
• Event Subscribers
• Queue API

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.