Randy Kolenko on Maestro and Drupal’s Emerging Orchestration Work

Across Drupal’s automation ecosystem, a shared orchestration discussion is emerging around how Maestro, ECA, and FlowDrop can exchange data and execution context while retaining the different workflow models they were built to handle.

Randy Kolenko, partner and senior architect at Nextide and creator of Maestro, describes Maestro as a business process workflow engine for long-running, multi-entity processes in which assignments, audit trails, human decisions, and state persist independently of any one Drupal entity.

The practical issue for Drupal teams is whether reactive automation, agentic data flows, durable human-in-the-loop processes, and external orchestration platforms can work together without bypassing Drupal permissions, moderation, validation, publishing controls, and audit expectations. Shared data contracts and execution-state models could improve interoperability, but they must not force Maestro, ECA, or FlowDrop to abandon the architectures that make each tool useful.

The DropTimes previously examined event-driven automation in a 2024 interview with Jürgen Haas on ECA and visible workflow execution in a recent interview with Shibin Das on FlowDrop. Randy’s perspective adds Maestro’s long-running business process model to that wider Drupal orchestration discussion.

Maestro’s Durable Workflow Model

TDT [1]: Maestro has been part of the Drupal workflow space for many years. For developers or site builders who know it only as a “workflow module,” how would you describe the specific problem Maestro is designed to solve?

Randy Kolenko: Maestro is a business process workflow engine designed to orchestrate sophisticated operations through automation. From simple serial tasks to dynamic, data-driven routing and human-led review cycles, Maestro provides the flexibility to model and scale even the most intricate workflows.

More specifically, the problem Maestro solves is the decoupling of business logic from the data itself. Maestro is used for long-running business processes where state, assignments, an audit trail, and human decisions need to persist independently of any one Drupal entity. Maestro serves as a bridge between human decisions, the Drupal platform, and an organization’s business processes. By coordinating workflows and automating tasks, it links everyday user actions with real productivity, helping organizations of all sizes increase efficiency. One thing that sets Maestro apart is Maestro’s Task Console: a dedicated human-in-the-loop interface where team members can complete assigned tasks and provide real-time input to keep automated workflows moving forward.

In standard Drupal workflows, such as Content Moderation, the workflow “logic” is a property of a single entity. If the entity is deleted or the state field is changed manually, the context is lost. Maestro solves the problem of multi-entity, long-running processes. For example, a single Maestro process can orchestrate a Webform submission, the creation of three different nodes, the generation of a PDF, and external API calls, all while maintaining a single, auditable “source of truth” for that entire journey that exists independently of any one piece of content.

You can create the process flow through our drag-and-drop template editor, assign tasks to humans, automate tasks through custom code, and even offload mundane tasks to AI. Humans interact with Maestro through our Task Console or a custom console that you can create with Views, providing a one-stop shop for people to see what they have been assigned.

Our tagline for what Maestro is helps define its positioning:

And specifically for what Nextide does with Maestro:

These aren’t just clever sayings; rather, they describe directly what Maestro is and does. If you’ve ever worked in an organization of any size, from small to enterprise, you’ve followed business processes. Onboarding, terminations, vacation requests, capital expenditure requisitions, expense report submissions, training requests, and gated approvals are all examples of business processes that are used daily. The Maestro workflow engine runs in the background, marshalling the process forward by:

• Assigning humans their tasks.
• Performing assignment notifications, reminders, and escalations.
• Maintaining variables for use within the flow for dynamic assignments, notifications, entity storage, and more.
• Executing automation tasks such as:
  • AI, AI Assistants, and Tool calls.
  • Setting variable values based on hardcoded or dynamically passed data from entities.
  • A logical “IF” task that detects task execution status codes or tests variable values to provide TRUE/FALSE branching capabilities.
  • Batch function tasks that can execute any custom-coded logic required for the task to complete.
  • Third-party connectivity tasks, such as our Activepieces task type, which allows you to fire off Activepieces workflows from Maestro.
  • ECA tasks that trigger ECA models.
• Trapping task execution results.
• Branching and parallel execution, including loopbacks within branches while other branches continue as normal.

What you should appreciate is that we’re talking about business processes and not Drupal-reactive processes. Business processes can route multiple different types of data, such as files, webforms, and content, and tend to last for hours, days, weeks, months, or more! Business processes happen on the timescale of humans, where processes happen “slowly,” in comparison with expecting a process to complete in microseconds, and must be tracked and stored to provide a fully auditable execution trail. This is what Maestro provides out of the box.

While ECA reacts to immediate system events and FlowDrop executes deterministic agentic flows, Maestro orchestrates the entire process lifecycle, governing stateful workflows that blend human decision-making with AI and system automation over the days, weeks, or months it takes to get work done.

Looking back on the way content moderation works, you can approximate simple business process workflows with state information embedded into a form or content type and present that to users to complete through Views. Maestro moves the state into the workflow engine itself and allows you to model, remodel, rewire, and change the process as needed. Once you embed workflow “smarts” into a document, if the workflow process changes, you’re forced to change the document. With Maestro, you redraw lines, add or remove logic tasks, or wire up engine-executed tasks rather than rearchitecting your solution. Business processes change with the changing shape of the organization, and Maestro allows you to adapt to those changes.

What people misjudge when automating business processes is how to handle the edge cases and exceptions. I don’t mean exceptions as in errors, but exceptions such as, “We do X, Y, and Z 95% of the time, but when this happens, we do A, B, and C.” That becomes a nightmare to code because exception handling, in our experience, changes regularly. Hardcoding exception logic or trying to wedge even more state information into documents becomes arduous. When you involve humans, a well-oiled machine can squeak very loudly. It’s how you minimize the squeaks and allow the business to continue running efficiently.

From Separate Connectors to Shared Orchestration

TDT [2]: Maestro, ECA, and FlowDrop have often been seen as parallel Drupal automation tools, even though they solve different problems. What changed recently in the conversation between you, Jürgen Haas, Shibin Das, and Dries Buytaert that made a shared orchestration discussion necessary?

Randy Kolenko: Moving data between Drupal and external systems, or vice versa, in a deterministic fashion provides structure, guardrails, and consistency. Right now in Drupal, we have solutions that address reactive, human, and data-centric flows, but the way in which they all interact is not supportable long term.

From Nextide’s perspective on Maestro, we’ve always had to interface with other platforms when automating business processes, which means that a Maestro process could be triggered by just about anything happening in the business. Take, for example, some common triggering scenarios we deal with:

• A file is dropped in a network location and needs to be approved before consumption.
• A third-party system sends data to subscribers and, as a subscriber, starts a Maestro workflow.
• Users manually start a Maestro workflow process, attach any type of file or data to the process, and then route and send that material to humans and third-party systems only when appropriate.
• Some kind of legal approval automation must happen at a specific time each day or week.

There are many more scenarios, but what you should see in just those examples is that we write the connectors between Maestro and the initiating system. The data that is incoming to or outgoing from Maestro is varied, and the structure for accepting that data is ambiguous. Now apply the same thought process to intra-Drupal orchestration.

• A Webform is submitted and the Webform’s Maestro handler is triggered, starting a Maestro workflow.
• New content is created, and ECA triggers and hands off approval of the entity to Maestro.
• A Maestro process requires publication of a node and triggers an ECA model to do so.
• A user is using a FlowDrop automation agent, and FlowDrop needs to trigger ECA or Maestro to carry out an established content-processing or approval flow.

The first issue is: how does Maestro talk to ECA or FlowDrop, and vice versa? What if a fourth module comes into play? The current approach is that you write connectors between your module and the others. This is an NxN issue in which you get an escalation of combinations just to allow the tools to talk to each other, and it quickly becomes unmanageable.

Second, what is the data being passed between the initiator and the receiver? Is it an integer value for the entity ID? Is it a fully loaded entity object? Is it a string? There isn’t a clear data contract between the modules, and as such, the connectors between the technologies perform the data transposition from one module to another.

The underlying premise for Orchestration is to allow for a proper handoff of data, a contract for data passing, and a way to create the orchestration so that it is seamless across Drupal. Dries has described this as a relay. When we can seamlessly pass the baton between Maestro, ECA, FlowDrop, and any other module within Drupal, we all benefit from it.

There is a fledgling Orchestration Initiative repository.

However, that is being used for the design specification, not coding.

I would characterize it as an emerging initiative. There is no experimental module, as this is an alignment of strengths Drupal already has and a discussion of how best to move this into the future.

At this moment in time, Maestro already has an ECA task that can fire off an ECA model and, in reverse, a Launch Maestro Workflow ECA Action. Likewise, with our Activepieces task and batch function task types, we can either push data to or pull data from external systems. Communication is not the problem. The consistency of the way we communicate is.

Maestro’s latest round of updates allows flows to be made available through the Tool API and allows Tools to be called within Maestro and Maestro AI. This makes Maestro discoverable for AI purposes and also begins to provide an API-based bridge between Maestro, ECA, and FlowDrop. I’ve worked with a number of Maestro flows that use this concept, and it works for both AI-enabled workflows and traditional data-driven workflows.

As data passing becomes more unified, the focus begins to shift toward how to make the entire ecosystem of automation engines work together more efficiently.

TDT [3]: ECA, FlowDrop, and Maestro are now being discussed together, but they appear to serve different classes of problems. In practical terms, when should a Drupal team reach for Maestro instead of ECA, FlowDrop, Drupal’s core content workflow tools, or an external orchestration platform?

Randy Kolenko: Indeed, all three modules solve different problems. Jürgen, Shibin, and I have talked about these differences at some length through our blog posts. The simplest first pass for deciding which tool to use is to understand what each tool provides.

• ECA automates reactive workflows dealing with Drupal events.
• FlowDrop provides deterministic agentic data flows.
• Maestro provides long-term business process orchestration and automation with support for human-in-the-loop workflows.

You then need to understand how the tool operates and how its architecture defines that operation.

• A Maestro process is measured in human timescales. Processes can take minutes, hours, days, weeks, or more.
• An ECA model’s execution is measured in milliseconds because, generally speaking, model execution happens during the same execution cycle as the event.
• A FlowDrop workflow execution is measured in milliseconds to minutes because it predominantly runs as an AI assistant or Tool.

There are many ways to create a solution to just about every problem. You could write a bunch of code to react to hooks yourself, or you could use ECA. You could create a state-based business workflow with content types, taxonomy, Views, and ECA, or you could use Maestro. You could vibe-code a CMS, or you could just use Drupal! You choose the right tool for the job.

Simply put, if you have a business process, you would use Maestro to automate it. The more in-depth reason you would choose Maestro is that it has a time-tested engine, called the Orchestrator, which provides the means not only to follow a pattern in a linear-forward fashion but also to allow loopbacks while managing the entire workflow state for human and automation tasks. If you loop back to a point in the workflow that precedes tasks that are currently open and available to execute, Maestro retains all the ancestry information, including dynamic branching, to understand which of those tasks become irrelevant and need to be scrubbed, yet retained in Maestro’s “memory” for proper process auditability. Maestro’s API is very robust and allows workflow administrators to work with developers, and now AI, to quickly create business automation solutions. If you can flowchart it, you should automate it with Maestro!

The key to using Maestro is understanding when and where to bring it to bear. For example, you need “n” approvals to happen for a new entity being created and only allow it to be published if all “n” approvers approve. If even one approver rejects it, the entire approval chain is rejected and routed back to the initiator. How many is “n”? It could be two, five, or ten, and the number is determined through a lookup into the organization’s HR system. There’s complexity in that example that goes well beyond Drupal’s content moderation and becomes a real chore to custom-code. Oh, by the way, the customer changed the specification partway through the project and now needs another gate stage! No problem. You would drag and drop your tasks and shift them around in Maestro’s Template Builder rather than breaking open all your code and redoing it.

TDT [4]: Maestro’s strength is durable, human-in-the-loop workflow that can persist beyond a single request or approval step. As Drupal explores a shared orchestration foundation, how do you protect that long-lived, stateful model while still making Maestro interoperable with tools built for faster or more immediate execution?

Randy Kolenko: Maestro’s engine, the Orchestrator, isn’t going away anytime soon. The reality is that Maestro’s architecture and engine structure are tuned for business processes. Maestro is not designed for workflows that need to execute in the same post-click cycle, such as reacting to a login or node save. We here at Nextide have always jokingly used this phrase to describe when not to use Maestro: “If you’re running a submarine, you should not use Maestro to automate anything in that environment!”

Maestro is not a real-time workflow engine. Maestro was never architected or intended to be a reactive engine. Faster or more immediate execution “solutions” have always existed: it’s called custom code. Nothing in Drupal is going to run faster than a hook call to optimized custom code that reacts to a node being saved and does exactly what you want as quickly as possible. This is as true for Maestro as it is for ECA and other tools.

Interoperability doesn’t mean Maestro, ECA, or FlowDrop goes away. Rather, when the most prominent work automation tools can talk seamlessly to each other and to the outside world, we are more likely to find common ground and work together to bring Drupal into a different realm of use cases.

As I noted previously, Maestro’s interoperability has always existed through specialized Maestro connectors, or task types, to other systems. Let’s look at your question from the other direction. With the rise of AI capabilities in Drupal and the advent of things like Tool API and the Orchestration module, interoperability becomes even easier and allows reactive tools to “slow down” and join the Maestro process automation revolution!

For context, that is a module that Dries and Jürgen created initially to support Activepieces integration, but it would also be used for things like n8n, Zapier, and other external work automation mechanisms. I have some Maestro merge requests available for the module as well.

The Orchestration module has not been updated for a while. However, it may become more prominent for external, Drupal-aware connectivity with these types of systems. Time will tell.

Until such time as humans are completely replaced in the workplace, Maestro will continue to provide human-in-the-loop automation, and reactive tools should be part of your toolkit as well.

TDT [5]: Maestro already connects with ECA through the Maestro ECA task module, allowing Maestro workflows to trigger ECA events and allowing ECA to spawn Maestro templates. What has that integration taught you about how Drupal automation tools should communicate with each other?

Randy Kolenko: Well, there’s something to be said about how “tidy” it is to have a task in your Maestro workflow template that says “ECA” and, magically, connects to a properly configured ECA model, with all the appropriate context from Maestro passed directly to ECA seamlessly and without issue. In that same vein, it can be arduous to write dual-ended connectors for every new system that appears.

With Maestro’s Tool API task, it becomes incredibly simple to pass data and context from Maestro to Tools and vice versa. However, the probability that I will never have to write a specific two-way connector to ECA, FlowDrop, or mystery-Drupal-module-X is likely zero. The reason may be specific to Maestro, but when troubleshooting a process flow that has failed years after its inception, there’s something to be said about the clarity a specialized connector provides. That’s the beauty of collaborating on orchestration: use the right solution for the job, increase interoperability between the solutions, and still provide a way to create first-class plugins or add-ons for those solutions.

So it is likely that the Maestro ECA task type and the ECA action that spawns a Maestro flow will continue to exist. However, you’ll also have the opportunity to use a Tool call, which is exactly how I recently wired up a Maestro workflow that used FlowDrop as a Tool.

Moving the Orchestration module’s concept forward would give external systems a potential one-stop shop for communicating with Drupal. While JSON:API already provides CRUD operations for Drupal entities, the Orchestration module can provide an interface for Activepieces, n8n, and other external third-party systems.

All of this combined shows how getting data and context passing right internally can lead to Drupal becoming a player in the control plane for organizations and external applications.

Data Contracts and Execution State

TDT [6]: The shared orchestration discussion has identified data handoff as one of the unresolved issues. ECA uses tokens, Maestro uses process variables, FlowDrop uses typed ports and edges, and Drupal core commonly uses context arrays. How should Maestro’s process variable model evolve to participate in a shared data contract without disrupting existing enterprise workflows?

Randy Kolenko: <raises a Spockian eyebrow> And why should Maestro change to suit others and not the other way around?

Joking aside, once something becomes part of Drupal core, the methodology becomes solidified. Let’s say ECA becomes part of Drupal core because reactive automation is incredibly vital to Drupal’s day-to-day operational reliability. If that ever happens, then you know for certain that ECA’s methods for data passing become “the way to do things.” Maestro would simply adhere to that methodology or those data contracts while preserving the way a business process engine traditionally works. ECA may undergo some transformation in data passing and handling as well, which in turn means Maestro would adhere to that standard.

When I look at Maestro today, it’s incredibly flexible in terms of its data storage. Specifically, Process Variables tend to store strings and integers, but we do not specify a type. If strict data typing were required for orchestration, that’s something Maestro could easily bring forward. For example, we already have the ability to perform simple increment or decrement loops in Maestro using Process Variables and an integer value for the increment or decrement amount. During that process, we internally cast the Process Variable and counter variables as integers anyway. This assumes that the workflow builder knows that you generally don’t increment or decrement strings! Revealing a type setting for each variable would be easily accomplished and would force Maestro to typecast values being injected into the system. So, from Maestro’s perspective, not much would change other than some enforced data rigidity.

The way I see it from Maestro’s perspective, the Orchestrator, process variables, entity identifiers, queues, processes, production assignments, templates, and every other concept or entity type will continue to live in Maestro’s realm. Maestro will adhere to the direction Drupal core or the Orchestration Initiative takes. If Tool API is the future, then we’re already there. If passing arrays of fully loaded entities is the future, well, let’s look at Tool API, shall we!

The bottom line is that nothing we’re doing with the Orchestration Initiative will disrupt existing enterprise workflows running on Maestro. What should gradually happen is that those existing flows may gain extra capabilities that may not be needed for every instance but are available when required.

TDT [7]: The shared orchestration discussion points to a gap in Drupal: there is no common model for tracking an active, paused, resumed, or completed execution across tools. From Maestro’s perspective, what would Drupal need from a standard execution-state model for this collaboration to work?

Randy Kolenko: Generally speaking, the three modules that run deterministic workflow patterns have a way to track the current state of execution. The most basic pattern is associating a runtime identifier with the state of execution. I’m not sure how useful that is, but an expanded version could be a primitive type in Drupal core used by Maestro, ECA, FlowDrop, AI Assistants, AI agents, cron queues, and anything else that wants to expose the state of its execution.

Shared execution state refinement:

If a shared execution-state primitive type, or set of types, were in Drupal core, it would likely include some basic information and would have to be refined over time to be suitable for general use. The most basic information would be:

• Execution identifier
• Timestamps
• Who or what is running
• The identifier from the system that is running
• The subsystem running
• Status
• Relationship identifiers for parents and siblings
• User context

However, different runtime engines have their own requirements, and some data from those engines would not be needed by other engines. It is likely that an AI agent will not need an associated Production Assignments entity like Maestro has, because AI agents don’t need to be assigned tasks in the way Maestro assigns them. But there would be value in having a centralized data structure that shows what is actually happening within the system.

We already have execution state at multiple layers within Maestro: at the process level and at the task level. So we know exactly what is running, what has been completed, and, in Maestro’s case, what has been looped over and how many times a loopback has happened.

However, it goes beyond execution state. For example, Maestro, ECA, and FlowDrop use different modelling tools. Each tool has a specific modeller because each tool is unique and handles modelling differently. So longer-term collaboration also means reducing barriers to user adoption.

If the question is one of unifying the execution pattern, that’s an architectural discussion that would radically change one or all of the work automation tools. From Maestro’s perspective, the Maestro Orchestrator will not change. We can implement, adapt, synchronize, or provide bridges to any new core data structure. The reality is that Maestro’s engine is tuned for a specific purpose and data structure, so those will not change. But that doesn’t mean Maestro cannot provide runtime information about its process state differently for a shared runtime monitor.

Should that become a first-class primitive in Drupal? Perhaps. However, unification of how we generate our execution patterns is a valid point of concern and something we can hopefully address through the initiative.

Drupal Governance for External Agents

TDT [8]: AI agents and external orchestration platforms are becoming more capable, but Drupal already has permissions, revisions, moderation, validation, publishing workflows, and audit expectations. If outside agents or external orchestration tools act on Drupal-managed content, what must Drupal expose so those systems can trigger or continue workflows while still respecting Drupal’s permissions, moderation states, validation rules, revisions, publishing controls, and audit expectations?

Randy Kolenko: The answer most likely lies in how the business or organization operates. “Touching Drupal” is a pretty open-ended phrase without any framing as to how important Drupal is in the orchestration of content. However, without grounding orchestration in Drupal’s governance model, why would you even use Drupal?

If governance is not an issue and AI is being used by someone to create content, why not just create a static page and push that to the hosting provider? There would be no need for Drupal. Similarly, if you’re running a marketing campaign and using external automation tools like n8n or Activepieces to manage the copy and approval process, Drupal becomes the public consumption service and is not involved in the content-generation workflow. Drupal is relegated to a simple content-consumption engine, publishing and unpublishing content while true governance happens externally.

Dealing with external systems touching Drupal content has traditionally been, and likely will continue to be, driven through user authentication and assigned permissions. This is a generic architecture used everywhere, not just in Drupal. Similarly, if you’re using something like Activepieces or n8n to automate external processes, calling those systems from Drupal would require some form of authentication, whether that is security by possession, basic or header authentication, or OAuth.

The Outside AI Initiative and the Orchestration module use, or will use, these concepts to protect what external parties can do with Drupal. With that user context come Drupal roles, permissions, and governance.

Let me give you a Maestro example:

We here at Nextide have customers who’ve been running Maestro for more than 15 years. The sheer amount of data they have is incredible. Excel files, Word documents, PDFs, and answers in webforms make their Maestro instances hives of knowledge, and 100% of it is sensitive corporate information.

All of that data is locked behind Drupal’s authentication and permission system.

All of those customers have external systems such as SAP as well.

SAP has work automation tools, but those customers chose to offload work automation to Maestro. Yes, we interface with SAP, but data and content governance reside in Drupal. Why? Because Drupal was designed for it. At the time these systems were created, SAP’s combination of content and work automation was more expensive than a custom Maestro and Drupal solution. The governance of who sees what, when, and how is managed by Drupal and Maestro and will continue for the foreseeable future because of data sovereignty, cost, and our custom reporting features.

From Maestro’s perspective, governance and access depend completely on what the system is designed to do.

If your Maestro instance is used for marshalling sensitive corporate documents, limiting external access is crucial. If you’re allowing non-data-sovereign agents to access your system, you had better limit what is accessible and validate the Drupal data-governance scheme you have implemented to make sure it is secure.

The same is true in reverse: what are you revealing to third parties that you really shouldn’t reveal? If you’re asking for a translation of a block of content, do you need to provide the entire entity, the fact that you’re using Maestro, and the Maestro Process and Queue IDs to the third party? Probably not.

As a general rule, nothing knows what is going on inside Maestro except the Maestro Orchestrator. Allowing an external agent to manipulate data within a running flow instance is a pretty good recipe for disaster. Your workflow design should take edge cases and exceptions into consideration.

Allowing an external agent to manipulate data within a running flow instance is a pretty good recipe for disaster.

TDT [9]: Outside AI is about external agents being able to work with Drupal from the outside, not about moving Drupal’s governance out of the CMS. From Maestro’s perspective, what would Drupal need to expose so an outside agent can safely trigger, inspect, or continue a long-running Drupal workflow without bypassing Drupal’s workflow model?

Randy Kolenko: The reality is that anyone who has used Claude Code for local Drupal development has probably experienced Claude calling Drush to test and execute newly written code or using Drush or CLI commands to invoke particular Drupal mechanisms. It’s fun to watch Claude run commands like:

Bash(vendor/bin/drush eval "
$node = \Drupal::entityTypeManager()->getStorage('node')->load(40);…

Claude can use commands like this to fetch context and make changes, as long as you allow it, in your environment. LLMs have run our Drush-based Orchestrator to advance workflows during testing. All of this is available today without much fuss. Locally…

The new Drupal CLI would benefit from having Tools exposed as commands so that those Tools are not only discoverable but usable through the CLI. However, with great power comes great responsibility. Using a CLI to perform CRUD operations on entities or spawn Maestro flows is incredibly dangerous without user context and permissions.

Outside AI, with MCP and Tool API exposed properly for external-agent consumption and use, is a natural step forward. Our Maestro Tools currently let you list and spawn Maestro Workflow Templates that have been flagged as public, as long as you have the required permissions. Spawning a Maestro flow includes the ability to seed Process Variables, which Maestro task types can transpose into Maestro Entity Identifiers for more tightly integrated Maestro-entity flows. This aligns with the Outside AI Initiative and with Tool calls respecting permissions. So we’re good to go!

At the time of this interview, what’s missing from Maestro’s perspective is a Tool that provides visibility into a Maestro workflow. As of right now, this is a deliberate decision on my part until I see how things mature in the Outside AI Initiative. The data within a Maestro process can be very sensitive, and having that data inspected through an external agent may not be optimal. But again, just as with Maestro’s user interfaces and tracing capabilities, if you have permission to access them, you can use them. So it is likely that, very soon, inspection of in-progress flows will become a Tool. This connects again to how Outside AI and even the Orchestration module work. Providing user context is key, and those permissions flow through Drupal’s permission system to allow or prevent particular features or data from being accessed.

Of course, someone could write a custom Maestro Tool that allows workflow inspection without any permission checking. That would be dangerous, and customers would need to understand the ramifications of what was being implemented.

The only caveat I have is that some of our busiest Maestro instances have hundreds of active processes, which can translate into thousands of active tasks. Providing as much information as possible about the particular process or task being inspected would improve performance dramatically.

TDT [10]: What would you like to see happen next in the Drupal orchestration discussion? Are we talking about shared vocabulary, shared APIs, reusable processors, experimental modules, a formal initiative, or something else?

Randy Kolenko: We’re talking about all of that and more. It takes a while to become grounded in a direction. But we’ve already created shared vocabulary and Venn diagrams, and discussed how we interact with each other.

At Nextide, we know that Drupal is a fantastically capable platform for delivering business process automation, and we have been beating that drum for 16 years and counting. We’ve been tirelessly trying to get people to realize that you can do so much more with Drupal than use it as a traditional CMS.

Orchestration discussions will likely shape how we can best collaborate to create a powerhouse orchestration platform. We already have some incredibly powerful tools, and they’re starting to talk to each other in ways that didn’t exist even a year or so ago.

A couple of demos I put together for the group combine Google Docs, Activepieces, Maestro, ECA, and FlowDrop and demonstrate how incredibly powerful Drupal already is! We, as a community, have not blasted our horns loudly enough on this topic. While we have a lot more work to do to align orchestration and point it in a direction, the capabilities and power already exist today.

For those who are curious, see a demo on Nextide’s YouTube channel that uses Maestro, Activepieces, and the Orchestration module.

I don’t have anything published that shows all three engines together and would be suitable for general consumption. It’s all much too specific or hidden behind an NDA!

However, Drupal governance remains intact because Drupal user context is used to run specific features. In the Activepieces demo linked above, we configure the Orchestration module to use a specific user account. That account is bound to the roles and permissions assigned to it.

Deep Ancestor Regeneration

TDT [11]: You also provided additional context on Deep Ancestor Regeneration. What is it, and what problem does it solve in real business workflows, particularly when AI is used to generate process patterns?

Randy Kolenko: Regeneration is a term specific to the Maestro workflow engine. It is the mechanism that allows a workflow to loop back and re-execute tasks that have already been completed.

Workflow automation isn’t only about automating a specific unit of work. It is also about how you generate the Maestro workflow template patterns themselves. Using AI to generate a Maestro workflow template is a great way to start your automation journey. If you asked Claude or ChatGPT to generate a Maestro workflow template, it would certainly generate a pattern for you to use. Would that pattern be what we at Nextide would create for your business? Perhaps. But it is likely that, as humans, we would automate a business process in a more human-centric way than a statistically engineered workflow would.

As humans, we tend to design workflows that branch into parallel paths or trunks aligned with how people operate in business processes. If one task needs to “loop back” because of an error, rejection, or logic, that loopback, or “regeneration” as it is called in Maestro, will happen within that trunk, leaving the other independent branches or trunks to continue operating untouched.

What we’ve noticed is that when AI is used to generate Maestro business processes, and a condition late in the process template requires a loopback, AI-generated flows tend to loop back to a much earlier task, bypassing parallel trunks. The issue that arises is that most engines are only “forward-looking.”

Let’s say a workflow contains four tasks. The flow is: Task A → B → [C AND D]. If C points back to A, Task D keeps running while A is started again. If A and B complete before D completes, you’ll have two Task Ds and one Task C again.

This scenario was always handled correctly by Maestro and was enhanced by the January 2026 release. The loopback from C to A in this example is known as Deep Ancestor Regeneration, in which Maestro has tracked all the ancestry information and the branches or trunks it followed to reach the point where the currently open and executing tasks exist.

In this scenario, Maestro doesn’t just rerun a task; it performs a smart reset. It identifies every “descendant” task that was spawned from that ancestor and intelligently terminates those tasks to prevent “ghost tasks” from remaining active in other parallel branches that are no longer valid.

As AI agents are used more, loopback scenarios can become more atomic. This means looping back to an ancestor so far back in the chain that all tasks that have already been executed must be executed again.

Further reading: Maestro’s Birthday and AI Engine Update on Nextide.

Maestro doesn’t just rerun a task; it performs a smart reset.