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.
Top comments (0)