Drupal's Modeler API released - learn about the benefits

Back in 2021, when ECA's architecture got designed and implemented, decoupling the processing of automations done by ECA from the UI, that's important to users to easily define those automations, has been a top priority. For the past 4 years, this has served the developers and end-users equally well. What's well known as the "Separation of concern" design pattern in modern software applications, has helped ECA a long way. However, we've also realized over the years, that we probably only accomplished parts of the goal. At least two aspects have shown weaknesses or were not possible at all:

The first shortcoming has been that ECA the processor, and BPMN the UI, have not been fully independent of each other. Certain pre- and post-processing of plugin properties and configuration forms, has been part of ECA. On the other hand, BPMN has seen limited feature improvements for a long time as it was tailored towards ECA.

This resulted in the second aspect that it has been impossible to re-use the UI for other requirements in the Drupal ecosystem. A graphical interface like the one from BPMN would make numerous other tasks so much more user-friendly:

• AI Agents with all the tools they need to get assigned and configured
• AI Automators with a combination of deterministic and artificial instructions
• Migrations into Drupal with countless plugins for data sources, processes, and destinations
• Views for database query building
• Data modeling with content types, bundles, fields, forms, and displays

The fact that users may have mixed feelings about BPMN also lead to the idea to replace it with other UIs like those from ReactFlow, n8n, or others.

This led to the invention and the development of Modeler API, a Drupal module that provides the link between complex config owners like ECA, AI Agents, Migration, and others on the one end, and replaceable UIs like BPMN and others on the other end. The main objectives are:

• Config owners and UIs (modelers) don't know anything about each other's capabilities or business logic
• Both ends can be replaced without losing any data:
  • users can edit configuration with the UI of their choice
  • the same config can be edited with different UIs
  • different config can be edited with the same UI, users don't have to learn new tools every time
• Developers should be able to focus on either the config owner or the UI, not both together
• Modeler API also provides all the generics like routing, list building, permissions, menu integration, logging, etc.

Version 1.0.0 has been published today, July 30th 2025, together with ECA 3.0.0 and BPMN.iO 3.0.0 while the AI module as well as AI Agents and Drupal MCP also have integrations in their latest dev branches, that should be published in stable releases pretty soon. Below, find out about the real benefits for both developers and end-users.

Re-usability

Everything being implemented in the Modeler API only needs to be done once, and will be used in many places. The same applies to all the UIs, also known as modelers, like the already existing BPMN, but there are others based on different paradigms and on other technologies already in the making. The Drupal Community now can leverage this framework for innovating faster, and by working together. With experts working on various UIs, everybody else benefits from their improvements and bug fixes, as not every module with complex configuration requirements needs to develop their own UI any longer.

Sure, the current versions of Modeler API and BPMN will most likely not yet cover all the requirements from the other modules that haven't yet started their integration with this new tool set. But Modeler API and its supporting UIs will continuously grow and adopt new features to also serve other scenarios. However, every improvement will be done once, and it will be used by many.

Fully decoupled UI

Applications, both inside and outside of Drupal, have their business logic to implement. Getting that right can be challenging, and it requires knowledge and experience from the maintainers and developers. For applications that also come with a need for complex configuration, that brings another set of requirements, that most likely are not within the knowledge and experience of the same developers and maintainers. Therefore, separating the generic purpose of an application from the task of providing a user-friendly way to configure such applications is key.

Separating the UI into their own modules, and even more so re-using them for different purposes, can be mind-boggling. The idea, that the same user interface can be used for defining workflow automations, AI Agents, Migrations, Views, and Content Types, sounds crazy at first. We're all coming from a world where each application brings their own set of tools to configure them. And the result is that users have to learn new UIs for every single task that they need to deal with.

Modeler API demonstrates that abstraction can be successfully applied even on that level. And for visually important distinctions, where the UI needs to render application-specific components to make more sense to the end-user, there is groundwork being done to support custom theming for each combination of config owner and modeler.

Maintainability

Separation of concern inherently comes with properly defined interfaces so that the various components can safely communicate with each other. Consequently, maintaining each of the components becomes exponentially more efficient. Focussing on a topic without having to care about other, maybe less known technologies, lets development move faster and increase the speed of innovation.

For the new ECA 3.0 version, this results in a brand-new release that has been unchanged in its core features. The entire code base remains unchanged, the config entity format is still the same, only the ECA UI submodule has been updated so that it provides a plugin that integrates with Modeler API, and everything else got removed. When it comes to processing the existing ECA models, it is still the same piece of software, upgrading is not risky at all. From now on, ECA can be maintained and improved without having to consider anything else than providing plugins and processing them correctly.

For the BPMN 3.0 release, the impact is even bigger. It's now a generic UI with a clearly defined scope, and maintainers will be able to improve its implementation and feature set a lot. Read more about it below.

Modern code base

While deconstructing and re-engineering ECA and BPMN such that generic features end-up in Modeler API, it made sense to also clean up the existing code base and leverage the latest upstream API improvements while getting the modules into the right shape for the future.

The big part has been in ECA:

• All plugins have been converted to use PHP attributes instead of annotations
• Configuration of all plugins is now defined by config schema and can now be validated
• Hooks have been converted into object-oriented classes with proper dependency injection

Of course, the Modeler API has been built from scratch so that it follows the latest coding standards. But the BPMN UI has been re-engineered from the ground up and now allows a much better integration, which we cover in the next chapter.

BPMN with much better Drupal integration

The BPMN UI is a JavaScript library maintained by different developers on a different platform. In Drupal, we "just" integrated that library as is, with very little adjustments for the Drupal environment. With the new architecture and much bigger ambitions, so that it will be suitable for so many more use cases and users, the 3.0 release comes with groundbreaking improvements that make a big difference today, but will also allow for significant improvements moving forward as well.

What's left from previous versions is the canvas, where users can drag around components of the diagram, add new components, and what not. But everything else has been replaced with Drupal-native components. That interface now feels much more like a Drupal application, and it makes end-users even more efficient as the workflow has been optimized for what's required in that context. Highlights of those improvements are:

• The property panel on the right side of the canvas is being used to configure the whole model and each of its components. This property panel was provided by the third-party library before, which came with unnecessary parts for the Drupal context while lacking convenient features that Drupal does really well. This property panel is now replaced by the off-canvas container from Drupal core, and the configuration forms are native Drupal Form API forms. That allows for tailored form field widgets as well as states, so that individual fields can be hidden depending on context.
• Extra widgets have been added to the canvas. They are built using the brand-new Icon API from Drupal core, and make numerous features accessible to end users without them having to remember shortcuts or other tricks. Zooming in and out, copy and paste even across browser tabs, a mini-map to better navigate within large models, searching, auto-layout, and more, those are the widgets that users will certainly not want to miss out on.
• Adding colour to each element in the canvas can be helpful in some cases too, as well as annotations. But that's just a teaser for what will be possible in the future, e.g. if different themes will be available so that models can be rendered more towards the purpose of the business logic that each of the models represents.

The BPMN module is now a real Drupal UI, not an external library any longer. This is also an enabler for even more innovation to follow, as we can now invite front-end experts to help move this forward in ways that haven't been possible with the previous architecture.

ECA improvements and more integrations

We've already touched on maintainability and modern code base above. Both topics are huge, mainly for developers and maintainers. End-users will benefit from that too, though, as the code quality, sustainability, and the feature set will increase altogether.

Having said that, ECA 3 also comes with new features and integrations that shouldn't be left out. Let's mention the 3 main improvements:

Config schema: this appears to be a technical improvement only, as ECA models can now be validated. But that also comes with a new feature that's often forgotten. As each configuration property now comes with a specific type, the translation framework of Drupal core can identify those properties that are user-facing and make them translatable with the same tool set that's already used for other parts of Drupal. Example use cases for that are messages and render elements displayed to the end user, or emails being sent out. All those components can now be used in ECA models just like before, and on a separate layer, the relevant content can be translated without having to increase the model's complexity.

Field Widget Actions: this is a brand-new module, currently provided by the Drupal AI module. It allows configuring entity forms such that extra widgets will be displayed next to any form field, and clicking on them will trigger a process in the backend which comes back with either some content to be filled into the related form field, or to open a dialogue with options to select from. Those field widgets are currently supported by AI Automators and AI Content Suggestions. ECA 3 now also supports them as well. ECA models can be built so that they take on such widgets to go through any type of logic to determine the suggested content for any field in entity forms.

AI Tools: ECA models can now also be built to be recognized as a tool not only by AI Agents, but also by the Drupal MCP server. It's difficult to imagine the scale in which this will enhance the overall toolbox that site builders now have available. The sky is your limit; if that phrase has ever been true, it's now and here.

Conclusion

Drupal as a framework, and Drupal CMS as an example product built within that framework, are getting a boost that will take them to a new level. Established modules like ECA and BPMN are getting major overhauls and improvements. The Modeler API itself introduces a platform that's yet to be adopted by the community. This blog post highlights the benefits for developers and end-users alike, the Drupal community as a whole can now take advantage of this and build its future on top of them.