Camunda released Camunda 8.9-alpha5 in mid-March. We have some highlights to share about this latest release. For a full list of features and updates for the release, we encourage you to check out the release notes.
- At a glance
- Task permission management
- Subfolder support in process applications
- Migrate user task process instances from job worker to user task
- Microsoft 365 inbound email connector
- Dynamic form references
- Orchestration cluster MCP server
- In brief
The Camunda 8.9-alpha5 release is designed to help enterprises move from just exploring automation to rolling it out more broadly within their enterprise. By strengthening governance and simplifying operations, this release gives organizations greater control over how automation is managed while helping keep delivery and day-to-day operations on track.
At a glance
Task-level access controls, introduced in this release, help ensure work is visible only to the right people. This supports least-privilege access, strengthens segregation of duties, and reduces audit exposure. Authorization is now also consistent across both the UI and API, giving security and platform teams a more dependable foundation for managing and scaling with confidence.
This release also helps teams modernize without disrupting live operations. User task implementations can now be updated while processes are still running, avoiding the cancel-and-restart workarounds that can introduce risk. At the same time, platform teams have more control over how noncritical integration errors are handled, helping processes keep moving while reducing unnecessary incidents and manual intervention.
Camunda 8.9-alpha5 also makes automation easier to manage in ways that align with how teams already build and collaborate. Improved project structure and repository alignment simplify governance and reduce handoffs between platform leaders and developers. Dynamic form references add even more flexibility, allowing teams to resolve forms at runtime so they can support different tenants, environments, or use cases without duplicating process diagrams or writing custom code.
Finally, the release continues to expand support for standardized, governable integrations. With native support for Microsoft 365 inbound email, organizations can bring a widely used enterprise communication channel into orchestrated processes through supported connectors rather than custom scripts.
Taken together, these enhancements help organizations adopt Camunda 8 with stronger controls, fewer operational workarounds, and more resilient automation. The result is a platform that is easier to roll out broadly, easier to operate day to day, and easier to support as orchestration becomes a core part of the enterprise architecture.
Let’s take a look at some of the highlights in the alpha5 release.
Task permission management
Task permission management for user tasks gives organizations more precise control over who can see and act on work. In previous releases, user task access was largely governed at the process definition permission level. If a user had permissions like READ_USER_TASK or UPDATE_USER_TASK for a process, they could effectively see and work on any user tasks created by that process, even when they were not the assignee or part of the candidate pool.
This gap could create challenges for business stakeholders, such as:
- Higher compliance and confidentiality risk. When task visibility is too broad, sensitive information can be exposed to the wrong people, creating issues for internal policy, audit requirements, and segregation of duties.
- More operational friction for teams. Organizations were often forced to choose between opening up Tasklist V2 too broadly or restricting it so much that people struggled to get work done. Neither approach worked well at scale.
- A bumpier migration experience. Customers moving from Camunda 7 or Tasklist V1 often expected task-level restrictions to be built in. When that wasn’t the case, adopting Tasklist V2 and the Orchestration Cluster REST API became harder than it should have been.
Essentially, without least-privilege task access, you could orchestrate the work, but you could not confidently govern who can see it.
But with this release, Camunda provides the granularity with task permission management to restore fine-grained, task-level authorization for Camunda 8 allowing customers—especially those migrating from Camunda 7 or relying on Tasklist V1’s task restrictions—to adopt Tasklist V2. By making task access more precise and predictable, we have solved these problems for stakeholders. Instead of relying on individual task IDs, permissions now follow task responsibility, based on who is assigned work or who is eligible to pick it up.
With support across the Orchestration Cluster REST API, Tasklist V2, and Identity, it ensures users only have access to tasks they are directly responsible for as an assignee, candidate user, or member of a candidate group. This feature brings Camunda 8 closer to the task visibility model customers expect from Camunda 7 and Tasklist V1, while strengthening governance and reducing unnecessary access.
Teams also get a secure default role out of the box for common task worker scenarios, along with more granular process-level controls when they want them.
That same model applies across both Tasklist V2 and the Orchestration Cluster REST API, organizations get a more consistent least-privilege approach across UI and API access.
Now you can:
- Confidently run shared process definitions across teams without leaking visibility.
- Reduce reliance on process-per-team diagram duplication just to enforce access boundaries.
- Move forward with Tasklist V2 and API-first task operations while keeping governance intact, especially in multiteam and multitenant setups.
For organizations moving from Camunda 7, this also makes the transition more natural by aligning task access with how teams already expect user work to be handled.
Subfolder support in process applications
Modern development teams rely on structured repositories and version control to manage complex projects. But until now, process applications in Camunda only supported a flat file structure, making it difficult to mirror the way teams already organize their source repositories.
As a result, process applications were harder to align with existing project layouts, and teams had a tougher time maintaining a single source of truth across development tools. Repository structures did not line up cleanly, teams often had to reorganize files to fit Web Modeler’s flat structure, and syncing with version control became more difficult than it should have been. Over time, that made project management more fragmented and harder to keep consistent across tools.
Let’s face it, enterprise automation programs rarely fail because someone cannot draw BPMN. They fail because teams cannot reliably govern, version, test, and promote process assets the same way they do application code. The net effect is operational: more manual steps, more drift between environments, and more friction when multiple teams contribute.
With Camunda 8.9-alpha5, you can now organize assets in your process applications into a hierarchy that matches your team’s needs and policies, instead of flattening everything into one directory.
Git Sync integration has also been extended, so Web Modeler can sync structured repositories, not just a flat list of files. This enhancement makes it much easier for teams to scale modeling practices across multiple teams and repositories.
For platform teams, this is really about governance and scale. It creates more consistency by allowing teams to use one repository structure across modeling, testing, and deployment, which helps reduce mistakes and review overhead. It also improves traceability because tests and documentation can live alongside the assets they support, making audits and reviews easier. And because the folder structure now aligns more closely with CI/CD expectations, it becomes easier to automate validation, packaging, and promotion.
Now development teams can maintain a single source of truth for all project assets, improving collaboration and reducing the overhead of managing mismatched file structures.
Migrate user task process instances from job worker to user task
If you are still executing processes that include depreciated job-worker user tasks in Camunda, you are blocking your teams from using the full set of the orchestration cluster APIs and modern user task capabilities. This lack of adoption also increases upgrade risk, as querying and management support for job-worker user tasks will be phased out with the 8.10 timeline.
For many customers, this forces a difficult choice: keep older patterns and carry forward technical debt, or depend on manual cancel-and-restart workarounds that interrupt active work.
This is especially important for organizations moving to Tasklist in V2 API mode, where job-worker based user tasks are not currently visible. Running instances could not be easily migrated to the recommended Camunda user task implementation, which left teams stuck on legacy API behavior and slowed broader modernization efforts.
To solve this, we have introduced user task process instance migration from job-worker to Camunda user tasks with this alpha release. This capability allows customers to migrate running process instances from the deprecated job-worker model to the recommended Camunda user task implementation without cumbersome workarounds.
With this feature, teams can reduce migration risk, keep in-flight work moving, and adopt the current user task model faster in order to prepare for the 8.10 release. That means less operational friction for platform teams, less technical debt for architects to manage, and a clearer path to standardizing on the latest Camunda task experience.
Microsoft 365 inbound email connector
Email is still one of the most common ways real work enters the business, whether that is a service request, an approval, a customer reply, or an internal handoff. But before this release, customers who wanted to turn Microsoft 365 inbound email into a governed Camunda process had to build that integration themselves. That meant working with Microsoft Graph API access, authentication handling, message parsing, correlation logic, and retry behavior, often through custom middleware or scripts that could be difficult to scale and hard to maintain.
Without a connector, teams were forced to rely on fragile mail rules, one-off automations, or introduce integrations with operational risk making email-driven processes harder to standardize. For enterprise teams, the challenge was not just technical complexity, but governance. When inbound email automation lives outside the orchestration layer, visibility drops, ownership blurs, and changes become slower and riskier.
This release addresses that missing piece with a Microsoft 365 inbound email connector built on the Microsoft Graph API. It gives customers a supported way to start or correlate processes directly from incoming Microsoft 365 email, without having to create and maintain the integration themselves. In addition, a delegated OAuth via refresh token was also added. There are three supported tokens with this new email connector:
- Bearer
- Refresh
- Client Credentials
This authentication model is closer to what enterprise teams expect from other Microsoft connectors and makes it easier to align with organizational security requirements.
Organizations that rely on Outlook and Microsoft 365 for day-to-day business communication can now bring that work directly into a governed orchestration layer. Service requests, approvals, exceptions, and customer emails no longer need to remain in inboxes or depend on disconnected automation. Instead, inbound email can trigger or advance workflows in a way that is visible, trackable, and easier to manage.
Emails can be read, moved to a folder, or marked as read with the new connector by selecting the appropriate postprocessing.
With the ability to trigger and advance workflow, organizations can reduce the need for custom integrations and manual triage, improve consistency in how email-driven work is handled, and give teams better control over a channel that often drives high-volume business activity. Organizations can gain faster response paths, stronger governance, and a more reliable foundation for scaling automation across Microsoft 365-based processes with this new connector.
Dynamic form references
Before this release, teams could technically use FEEL expressions for form references at runtime, but that capability was largely hidden in practice. This limitation created friction for customers who needed the same process to serve different tenants, regions, environments, or business cases. They often had to duplicate BPMN diagrams, maintain separate deployments, or push form-selection logic into custom code.
That gap matters because static form bindings limit reuse. When a process needs to show a different form based on tenant, locale, product line, or feature flag, a hard-coded form ID quickly turns into a maintenance problem. Customers are left managing unnecessary “extra copies” of models incorporating different forms, which increases complexity and makes form behavior harder to understand, govern, and evolve over time.
With this release, the Form ID field now supports FEEL expressions in the modeling experience, so teams can define form selection declaratively in the BPMN model. This approach aligns the tool with what the process engine already supports and makes dynamic form resolution far more discoverable for process authors.
This new feature allows teams to keep a single reusable process model while selecting the right Camunda form at runtime based on business logic or process variables. This reduces duplication, lowers the amount of custom code needed around forms, reduces maintenance, and simplifies deployment across tenants and environments. It also makes advanced behavior easier to model, easier to maintain, and easier for more users to adopt, which helps organizations scale process standardization without sacrificing flexibility.
This enhancement is part of a broader effort to strengthen FEEL as the single expression language across BPMN, DMN, and forms and to make advanced capabilities, like dynamic forms, approachable for non‑experts at Camunda.
Orchestration cluster MCP server
In previous releases, there was no standard way for AI applications to discover and invoke Camunda capabilities, so each integration needed its own approach for authentication, tool definitions, and response handling. This increased the timeline to enterprise adoption and just made experimental cumbersome.
Without a common interface, teams had to manually define what an agent could do, how to call Camunda, and how to interpret the results. As more AI use cases emerge, integration patterns start to fragment because the same cluster capabilities are exposed in different ways to different applications, increasing duplication, governance overhead, and long-term maintenance effort.
Camunda 8.9 addresses these issues by introducing the Orchestration Cluster MCP Server. This new API surface is built directly into the Orchestration Cluster that exposes operational capabilities through the Model Context Protocol (MCP). Instead of creating custom contracts for every AI integration, organizations can now connect MCP-compliant clients through a standardized, stateless interface with built-in tool discovery, structured schemas, and the same authentication and authorization model used by the existing REST API.
This server gives teams a consistent way to connect AI agents to Camunda, reduces custom integration work, and makes it easier to scale from isolated proofs of concept to repeatable enterprise patterns. Because tools can be discovered dynamically at runtime, agent-based applications become easier to build and adapt. And because access is governed through familiar cluster security controls, organizations can extend AI-driven operations without introducing a separate integration model. The result is a more reusable, secure, and scalable foundation for bringing AI into process operations.
For more information, please visit our documentation on the MCP server.
In brief
Camunda 8.9-alpha5 helps enterprises scale process orchestration with fewer tradeoffs between governance, delivery speed, and operational stability. Across this release, the focus is clear: give teams stronger control over who can access work, reduce the need for fragile workarounds, and make it easier to modernize without disrupting active operations.
From task-level permissions and smoother migration from Camunda 7-era patterns to more resilient connectors, reusable modeling, and standardized AI integration, these updates make Camunda easier to roll out, easier to operate, and easier to govern as automation becomes a core part of the enterprise architecture.
We hope you enjoy our latest minor release updates! For more details, be sure to review the latest release notes as well. If you have any feedback or thoughts, please feel free to contact us or let us know on our forum.
Don’t forget to check out our release notes to see all the new features provided with Camunda 8.9.0-alpha5.
