ECA, FlowDrop, and Maestro Maintainers Explore Shared Drupal Automation Layer

Maintainers of three Drupal automation and workflow projects are discussing a shared backend layer that could allow processors and data contracts to work across ECA, FlowDrop, and Maestro. The work remains at the architectural planning stage. It does not signal a merger of the projects or their user interfaces.

The discussions involve Dries Buytaert, Drupal founder and project lead; Jürgen Haas, maintainer of ECA; Shibin Das, maintainer of FlowDrop; and Randy Kolenko, maintainer of Maestro. Shibin shared the details with The DropTimes during a dedicated Zoom meeting. He said the participants have been discussing common graph models, shared language, data contracts, and reusable processor patterns.

The proposal addresses duplication across Drupal automation tools. Shibin said similar transformation logic is often rebuilt for different systems because each orchestrator expects its own objects, context, or execution model. A shared contract could allow a processor to define its inputs, outputs, and behaviour in a way that multiple Drupal automation tools can interpret.

The maintainers are not proposing a single replacement product. Each tool would continue to make its own decisions about interface, execution model, scheduling, and user experience. The shared layer would instead focus on the backend contracts needed for interoperability.

ECA handles immediate automation within Drupal and is designed around operations completed during the same request. Maestro supports long-running workflows that can span days or months and involve multiple user actions. FlowDrop focuses on data-first automation, where the flow describes how data is transformed rather than only which process runs next.

Shibin said this distinction matters because processors often need only a specific value, such as text, rather than a full node, form state, migration object, or workflow-specific object. A data-oriented contract could allow the same processor to work across multiple contexts. That approach would reduce the need to rebuild similar logic for every orchestration engine.

The shared-layer discussion also reflects governance concerns in Drupal automation. Shibin said moving workflows outside Drupal can make permission checks, access control, and observability harder to manage. He argued that keeping more orchestration logic within Drupal can help teams align automation with the platform’s existing permission and governance model.

The maintainers are still defining how much of the backend can be shared and how much should remain specific to each project. Shibin said they expect the picture to become clearer over the next few months as they compare what is common and what is complementary. More details may be presented around DrupalCon Rotterdam 2026, scheduled from 28 September to 1 October 2026.

No shared release has been announced. The significance of the discussion lies in whether Drupal workflow tools can share backend contracts while preserving their existing interfaces and use cases. For developers, the outcome could reduce duplicated processor work and make automation patterns more reusable across Drupal projects.