The first agentic essentials article was about how agentic orchestration works. This one is about when to use agentic orchestration at all. That is a different question, and I think it matters more. Teams often reach for AI before they have confirmed it fits the problem they actually have.

In this article I compare three problem shapes in the same baggage-support world: a fixed workflow, a rule-based decision, and a messy inbound email that neither of those can handle cleanly. The rule-based part uses DMN, short for Decision Model and Notation, which is a standard way to write business decisions as explicit rule tables. The goal is one honest threshold for when agentic orchestration is the right call and when it is not. I will continue to use the missing-baggage example here.

Three Different Problem Shapes

All three examples below stay in the same baggage-support world. What changes is how much the system already knows when the case arrives, and how hard the next step is to pre-model.

When A Normal Workflow Is Enough

Imagine the passenger uses the portal. They pick “missing baggage”, enter a booking number and bag tag, and confirm their contact details. From there, the process follows the same order every time: query for the bag, contact the last known airport, provide a voucher and then update the passenger.

The steps are known before the case starts. I would not add AI here. Every model call adds latency and cost. On a step with no judgment in it, that overhead buys you nothing.

When DMN Is The Better Fit

Now look at the next action decision. A policy might allow different voucher amounts based on route length or delay. That is a business rule, not an open-ended judgment call.

This is where DMN fits better than AI. You put the policy into a decision table. The engine evaluates the inputs and returns a result. You can also explain later exactly why the outcome was accepted or rejected.

Every rule is visible. Every outcome is traceable. No model call needed. If you want to go deeper on DMN, I covered it in a separate article.

When Agentic Orchestration Makes Sense

Now take the messy version. The passenger sends a plain email. Their bag didn’t arrive, they have moved to a different hotel, and they only have an old photo of the tag.

The first useful step is not obvious. The system might need to check whether a claim already exists, ask only for the missing hotel address, and then continue the search. That is a much better experience than a rigid form that asks for everything upfront or a decision table that refuses to run without clean input. That is where agentic orchestration starts to make sense. The AI works within guardrails and has access to a small set of approved tools, but it decides which tool to use first based on reading the message.

But messy intake is only one case. The same reasoning applies mid-process. A process engine follows the path it was given. A rule table matches conditions to outputs. Neither one reasons. If the passenger’s next message mentions that their medication was in the bag, a fixed flow has no branch for that. A DMN table has no row for it either. An agentic step can read the message, understand what changed, and act on it, for example by sending a care voucher or escalating the priority, without a developer having anticipated every situation the passenger might bring up.

The Cost Of AI

This part often gets skipped in demos. AI adds real overhead:

• Every model call costs money.

• Responses are slower than a rule table.

• The behavior needs evaluation on real, messy inputs.

• Operations teams get one more thing to monitor.

If there are only a few known next steps, that overhead is usually not worth it. A workflow or a decision table will be easier to run and easier to explain.

Start From The Problem, Not The Tool

Do not start from “where can I add AI?” Start from “where does structured modeling stop being enough?” For most processes, a workflow or a rule table is already the right answer.

What’s Next

• Many processes just don’t need AI. If the path is known, use deterministic BPMN. If the decision has clear rules, use DMN.

• Agentic orchestration fits when the input is messy, the next step depends on interpretation, or the situation can change mid-case in ways that were never modelled.

• The fundamental difference is reasoning. A process engine follows its path. A rule table matches its conditions. An LLM reads the situation and decides what to do next.

• AI adds real cost and operational overhead. Start from the problem, not the technology.

Once you decide that agentic orchestration is the right fit, the next question is practical: how does the AI step actually call tools and systems from inside the process? That is what the next article is about.

Imagine you are waiting for a text message with a one-time code. You cannot log in without it. And it is not just any code. It is your code, for your login attempt.

In Camunda, that is a message. Your process instance waits, and something has to publish the message that wakes it up. The boring part is that you often end up writing the same tiny “publish a message” worker again and again.

This post is about avoiding that work. With the Message Sending Connector, you can use the connector runtime to publish messages for you. You only configure message name, correlation key, and payload mapping. No custom worker code for every new message.

When A Process Waits For A Message

Let’s use a simple example. An order process reserves stock, then waits for a payment confirmation.

In BPMN, that waiting point is e.g. an intermediate message catch event. It means: “wait here until a message arrives.”

Many instances can be running and waiting for the same message name. So we need a way to make sure the right message wakes up the right instance.

Note: Message correlation also matters in other places, like message start or boundary events. The matching idea is the same. I use the intermediate catch example because it makes the “waiting instance” easy to picture.

A Quick Intro to Correlation

The Three Pieces: Subscription, Message, Match

When a process instance reaches an intermediate message catch event, it creates a subscription in the engine. The subscription is like a note pinned on the wall:

• Message name: what the instance is waiting for (for example, PaymentReceived)

• Correlation key: which instance it is meant for (for example, the orderId)

An incoming message has the same two fields, plus optional payload data (variables).

Now the engine correlates:

1. Find subscriptions with the same message name.

2. Compare the correlation key on those subscriptions with the correlation key on the incoming message.

3. If there is a match, continue that instance.

If the message arrives too early, Camunda can buffer it for a limited time and correlate it later when the instance reaches the waiting point.

The correlation key is the address of the message.

A correlation key is usually something you already have in the business:

• Order id

• Claim id

The key should be stable and specific. If two instances could share the same key, it is not specific enough.

Before The Connector: A Custom Worker Every Time

Imagine you want to send a message to another process. This can be an intermediate throw and catch event, or even a message end event.

Typically, that means a small job worker that publishes the message, since the engine only waits for the external trigger. It is rarely hard, but it is repetitive. Both send events have to be implemented.

It sounds small, and it often is. But it comes with real work:

• Credentials and environment configuration

• Mapping and validation (what if the orderId is missing?)

• Retries and operations (logs, monitoring)

And you repeat it for every process that needs message based waiting.

Here is what “publish a message” can look like in code. It can feel too small to deserve its own worker:

client.newPublishMessageCommand()
  .messageName("PaymentReceived")
  .correlationKey(orderId)
  .variables(Map.of("paymentId", paymentId))
  .send().join();

It is straightforward. But “straightforward” still means code to write, deploy, and run.

And if you have more than one process waiting for messages, you repeat the same pattern. Each new message tends to create another “small worker”, another deployment, another thing to operate.

After The Connector: Use The Runtime

The Message Sending Connector is an outbound connector that publishes a message for you. Instead of implementing message publishing as code, you model a step and configure it.

The key idea is simple: you stop rebuilding the “publish a message” runtime. You use the one you already have, if you run connectors.

It is also a nice companion to the inbound Webhook Connector. Webhooks bring events into the engine. This connector helps you send events inside the engine for inter-process communication.

What You Configure

At a high level, you configure three things:

• Message name

• Correlation key

• Variables (payload mapping)

You still need to understand correlation. The connector cannot guess the right key for you. But it removes the repeated implementation work.

What The Runtime Gives You

The connector runtime gives you the operational basics you usually have to rebuild in custom code:

• Auth and connectivity to the engine

• Retries and Idempotence (via message id)

• A standard place to configure and change the mapping

If you are teaching a process to talk to another process, or sending a “ping” back into a waiting instance, this connector removes a lot of friction. Your BPMN model shows clearly where the message gets published, and your runtime stays smaller.

Summary

• Message correlation matches a message name and correlation key to a waiting subscription.

• Before the connector, teams often implement message publishing as a small custom worker, over and over again.

• With the Message Sending Connector, you configure publishing and reuse the connector runtime instead of writing worker code each time.

When people talk about Camunda connectors, they usually think about the big ones. HTTP. REST. Kafka. All the things with long config panels. But the tiny webhook connector often gets ignored. And that is a shame. It is one of the most useful pieces in the toolbox because it solves a very real problem. How do you let the outside world safely poke your process without exposing a full API or writing boilerplate?

The webhook connector gives you a simple endpoint you can call from anywhere. There is no controller class, no extra service. Just configure it in your model and you are done. And even if it looks simple, it has a lot of power hidden in a few fields.

What the Webhook Connector Can Do

Using a webhook to start a process is often easier than using a regular start event because almost every system can send a plain HTTP request. The caller does not need a Zeebe client or any workflow knowledge. You give them a URL and they can trigger your process right away.

A webhook also lets you send a clear response back. You can return a simple confirmation, an instance id or an error message. This keeps the integration easy to understand and avoids guesswork on the caller side.

Endpoint Configuration

Every webhook needs an address, and the connector gives you full control over how that address looks and how it behaves. The endpoint configuration defines two things. The HTTP method the webhook will accept and the id that becomes part of the final URL.

Once the method and id are set, the connector exposes the webhook at a fixed URL after deployment:

https://<region>.connectors.camunda.io/<cluster_id>/inbound/<webhook_id>

The region and cluster id come from your Camunda setup. This makes the URL predictable and easy to integrate. You can hand it over to any external system, and they can start sending requests without any additional routing or infrastructure.

HMAC Authentication

The webhook connector supports HMAC (hash-based message authentication code) authentication. This is useful when you need a simple but secure way to verify that the request really comes from the expected sender. Many platforms use HMAC for webhook signing because it does not rely on passwords or tokens that can be reused.

To achieve this, the sender takes the payload, combines it with a shared secret and runs it through a hashing algorithm. The result is a signature. The receiver does the same calculation. If both signatures match, the message is trusted. If not, the request is rejected.

The important part is that the shared secret never travels over the network. Only the signature does.

Authorization Options

Webhooks are public entry points, so you usually need some protection. The connector supports three common patterns that work with most systems.

Basic Authorization

Basic auth is simple and widely supported. The caller sends a username and password in the Authorization header. The webhook connector checks the values and only accepts the request if they match. The password comes from the connector runtime’s secret store, not from your BPMN model.

This is a good fit when you control both sides or when the calling system only supports basic auth.

API Key Authorization

Many webhook providers still use API keys. The connector supports keys in headers or in the request body. You define an expression that selects where the key comes from. The connector reads it and checks it against the stored secret.

This works well for simple shared-key setups or when you need a lightweight alternative to JWT.

JWT Authorization

If the caller sends JWTs, the connector can validate them before the workflow starts. You provide an expression to extract the token and the rules for checking it. The connector verifies the signature and claims. This is useful when the caller uses an identity provider and you want to avoid static credentials.

Special Webhook Features

Verification Expression

The one time verification is evaluated first when a message arrives. It solves a very common problem. Many platforms do not trust a webhook until they have checked that it actually exists. They send a special request before sending any real events. This request usually includes a challenge field or a flag that marks it as a verification attempt.

Without this feature you would have to create your own API layer, detect the verification request yourself and make sure you do not accidentally start a workflow. The webhook connector handles all of this for you. You write a small expression that detects the handshake request. When it matches, the connector returns a custom payload and stops. No process instance is created, no variables are set and no business logic is triggered.

Activation Condition

The activation condition solves a different problem. Sometimes a request is valid at the HTTP level but does not contain the data you need to start a process. Without this feature you would either create a broken process instance or you would have to wrap the webhook behind a custom API.

The activation condition lets you block bad or incomplete requests before they turn into running processes. You write a FEEL expression that returns true or false. If the condition returns false, the connector responds with a 422 and stops.

You can also turn off “Consume unmatched events” to prevent anything from slipping through.

Response Expression

When you start a process from a webhook, the caller usually wants to know what happened. Did the process start and what is its key? In many systems you would need to create a controller, map the result and build a custom JSON response.

Here you just define the response in the model. After the process instance is created the response expression is evaluated. You can return any data you want, e.g. the instance key. You can also map values from the original payload or from variables set by the connector.

This makes the webhook feel like a small but well behaved API endpoint. The caller gets a meaningful response and your integration becomes easier to work with.

Instance Correlation

When you use the webhook connector as an intermediate event, the behavior is different from a start event. Instead of creating a new process instance, the webhook should continue an existing one. This creates a new challenge. You might have several running instances waiting at the same webhook. The connector must know which one should continue.

Correlation solves this by matching incoming data with a value inside a specific process instance. When the values match, the message goes to the right instance and the workflow continues.

How Correlation Works

You configure two things.

1. A correlation key inside your process. This is usually a variable like an orderId or any other unique identifier.

2. An expression that extracts the same value from the incoming webhook payload.

When a request arrives, the connector runtime evaluates the expression. It compares the extracted value with the correlation key of all waiting instances. If it finds a match, that instance continues. If not, nothing happens.

This makes the system safe even when many instances are waiting at the same intermediate event.

Handling Late Messages

There are cases where the callback arrives before the process reaches the waiting state. The connector can handle that too. You can enable message queuing for a certain time window. The webhook call is temporarily stored. When the process instance arrives at the intermediate webhook, the queued message is delivered immediately and the workflow continues.

This makes your integrations more robust. Slow workflow. Fast callback. Out of order delivery. It does not matter. Correlation and queuing make sure everything lines up correctly.

Conclusion

The webhook connector solves real problems. It gives you a safe entry point into your model, lets you validate requests, handle callbacks and control when a process should start. And you get all of this without writing extra controllers or custom code.

If you only ever used it to start a process, you have more to explore. It is a flexible way to let external systems talk to your workflows while you stay in control.

On my next post I will show a real life example on how you can validate your request payload with the mechanisms above. Stay tuned!

The BPM lifecycle doesn’t stop at execution or monitoring. Once a process runs smoothly, the next step is to make it better. Operate shows what’s happening right now, but real improvement means looking at patterns over time. That’s where Optimize helps.

Camunda Optimize gathers past process data, groups it, and shows clear insights. It helps teams see how well processes actually work and where they can be improved to save time, cut costs, or stay compliant.

From Monitoring to Improvement

While Operate focuses on the health of single process instances, Optimize looks at many of them together to spot patterns. It helps answer questions like how long the average process takes, where delays happen most often, and which paths are used the most. These insights go beyond fixing issues and support ongoing process improvement.

In a vacation request example, Optimize can show if manager approvals take longer than expected, if HR updates are often delayed, or if rejection rates are higher in certain departments. With that data, teams can make informed decisions like adjusting approval chains, automating more steps, or shifting resources where they’re needed most.

KPIs and Dashboards

A key feature of Optimize is the ability to define key performance indicators for processes. KPIs such as average completion time, cycle time per activity, or incident frequency can be tracked across many process instances. These KPIs aren’t entered manually but come directly from workflow data recorded by Zeebe. Every step in a process instance is logged as an event in the distributed log. Optimize reads this event stream through exporters and stores it in its own data store for analysis.

This means KPIs are always based on real execution data. The duration of a process is measured from the timestamp of the start event to the timestamp of the end event. The time spent in a user task is taken from when the task was created to when it was completed. The number of incidents comes from error events logged during execution. By combining these raw data points, Optimize can calculate aggregated KPIs across thousands of instances with precision.

Alongside these technical metrics, Optimize also supports analysis based on custom process variables. Any variable in a process instance can be used in reports and dashboards. For example, in the vacation request process, the approval result variable can show how many requests were rejected. Another variable, such as approval time, can measure how long supervisors take to complete approvals — showing how long the process stays in that activity. These values are captured during execution and aggregated across all instances, providing insights that go far beyond basic technical monitoring.

Dashboards bring these insights together in charts and tables that update automatically as new data comes in. For management, this means having direct visibility into whether automation is meeting its goals. For operations teams, it shows where inefficiencies or bottlenecks are tied to specific business conditions.

In practice, a dashboard for the vacation request process might combine technical KPIs like average cycle time with business KPIs like the percentage of rejected requests or the average approval time per supervisor. This gives a complete view of both operational efficiency and business outcomes.

Who Uses Optimize?

Optimize is used by different stakeholders depending on their goals. Business analysts use it to understand how processes behave in reality and where redesigns are needed. Operations teams use it to spot bottlenecks and measure the impact of changes. Management uses it to track strategic KPIs and support decisions about further automation.

The value of Optimize is that it connects all these perspectives. It gives everyone a shared view of how processes perform and makes sure improvement discussions are based on real data, not assumptions.

Closing the Series

This final part completes the journey through the BPM lifecycle with Camunda. We started with the need for automation, explored how models become executable and are deployed, looked at Camunda’s architecture, compared connectors and workers, and saw how processes are monitored in Operate. Optimize closes the loop by providing the tools to keep improving processes over time.

The combination of BPMN for modeling and Camunda 8 for execution, monitoring, and optimization creates a complete setup for process automation. It ensures that processes are not just documented and automated but also transparent and adaptable. This ongoing cycle of modeling, execution, monitoring, and improvement is what makes automation sustainable and effective.

With this series, you now have an overview of how to move from BPMN diagrams to a modern process automation platform. The next step is to apply these ideas to your own processes, start small, monitor results, and keep improving continuously.

In the BPM lifecycle, modeling and execution are only the beginning. Once processes are running, the next step is monitoring. Without monitoring, it is impossible to know whether processes are working as expected, whether they are stuck, or whether changes are needed. Camunda 8 provides a dedicated tool for this: Operate.

Operate connects directly to the workflow engine and provides visibility into running and completed process instances. It is the place where developers, operators, and business owners can check the health of their automation, resolve issues, and even update running instances when process definitions evolve.

Monitoring Processes in Real Time

When a process definition is deployed and instances are started, Operate shows every instance and its current state. You can see which activities have already been completed, which tasks are active, and where the process is waiting. This visualization is especially helpful for long-running workflows, where many steps are automated but others require manual approvals.

For example, in the vacation request process, Operate can show that an instance is currently waiting at the manager approval task. Another instance might already be at the HR update step, while a third has been completed. This visibility allows stakeholders to verify that processes are moving forward and to identify bottlenecks if instances pile up at specific steps.

Incident Handling

Not every process runs smoothly. Sometimes a worker fails to complete a job, an API returns an error, or a variable is missing. When this happens, Operate creates an incident. An incident marks a process instance that cannot move forward until the issue is resolved.

Incidents can be inspected in detail. Operate shows the failed job, the error message, and the variables that were present at the time. Operators can retry the job after fixing the problem, either by correcting variables or by resolving the underlying system issue. This ensures that a single failure does not block the entire workflow but is instead addressed in a controlled way.

Process Migration

Over time, process models evolve. A vacation request process might be extended with new approval rules or modified to include additional data checks. While new instances will run on the updated version, existing instances may still be running on the old definition. Operate supports process migration, which allows running instances to be moved from one version of a process to another. All you have to do is assign a mapping for each activity in the new version.

Migration ensures consistency and reduces the need to maintain multiple process versions in parallel. For example, if new compliance requirements demand that all vacation requests include a legal confirmation step, existing running instances can be migrated to the new definition. This feature bridges the gap between continuous process improvement and operational stability.

Why Monitoring Matters

Monitoring is a critical step in the BPM lifecycle because it closes the loop between modeling and execution. Without it, processes would run blindly, and issues could only be detected after they caused significant problems. Operate ensures that process automation is transparent, resilient, and adaptable to change.

By combining real-time visibility, incident handling, and migration, Operate gives organizations control over their running processes. This control builds trust in automation, as stakeholders know that processes are not only executed but also actively supervised and maintained.

Looking Ahead

Monitoring is not the end of the cycle. The final step is optimization, where data from many process instances is analyzed to improve efficiency and eliminate bottlenecks. In the next article, we will look at Optimize, Camunda’s analytics and reporting tool, and see how it supports continuous process improvement.

Once a process model has been deployed, it usually needs to interact with other systems. A vacation request does not only exist inside the engine; it might need to send an email, update a record in the HR system, or fetch data from a calendar. In Camunda 8, these interactions are handled either through workers or through connectors. Both approaches let the process engine delegate work to external components, but they differ in complexity, flexibility, and the amount of technical effort required.

Workers: Technical but Flexible

Workers are the most fundamental way to connect Camunda to the outside world. A worker is a program that subscribes to a task type in Zeebe. When the engine reaches a service task of that type, it creates a job that the worker can fetch through the gRPC API. The job contains the relevant process variables, and the worker executes the logic before reporting the result back to Zeebe.

Because workers are implemented in code, they are very flexible. A worker can be written in languages like Java, Go, or Node.js and can perform any logic that the programming environment allows. In practice, Java has become the de facto standard for building workers. The ecosystem around Java, Spring, and Spring Boot provides excellent library support, dependency management, and production-ready patterns. This makes it easier to build robust integrations that connect to databases, APIs, or enterprise systems. For example, in the vacation request process, a Java Spring Boot worker could connect to the HR system’s API, validate vacation balances, and update employee records in a few lines of code using standard libraries.

The downside of workers is that they require development effort, deployment of a service, and lifecycle management for that service. This is why they are typically chosen in environments with dedicated IT teams, strong development practices, and complex integration requirements.

Connectors: Prebuilt and Easy to Use

Connectors were introduced in Camunda 8 to simplify common integrations. A connector is essentially a prebuilt worker packaged with configuration options that can be set directly in the BPMN modeler. This means process designers can configure integrations without writing code. Connectors come in different forms, each suited to specific scenarios.

Protocol Connectors

Protocol connectors allow processes to interact with external systems over standard protocols. The most widely used example is the REST connector. With it, a process can call any REST API by configuring the endpoint, HTTP method, authentication, and payload. In the vacation request example, the REST connector could be used to call an internal HR API to check vacation balances or to update employee records once a request is approved.

Connector Templates

Connector templates build on top of the protocol connectors but simplify their configuration for recurring use cases. A template defines the request structure and parameters for a specific API, so process designers only need to fill in the variable values. For example, a company might create a connector template for their HR system’s REST API. Instead of configuring the full HTTP request every time, the template provides fields like “employee ID” and “vacation dates,” making integration straightforward for business users.

Other Connectors

Beyond protocol-based communication, Camunda provides connectors for specific technologies and platforms. These include messaging systems such as Kafka, email services for sending notifications, and cloud storage platforms like AWS S3. These are available out of the box and run within the Camunda Connector Runtime. They can be configured directly in the modeler, which makes them quick to set up for common integration scenarios. For example, the vacation request process might use the Mail connector to notify employees about approval decisions or the Kafka connector to publish an event that other services subscribe to.

Custom Connectors and the SDK

In addition to the out-of-the-box options, organizations can develop their own connectors when specific integrations are required. These custom connectors are implemented using the Connector SDK and must be hosted externally, usually as containerized services in the organization’s infrastructure. They behave like packaged workers, but once registered, they appear in the modeler like any standard connector. This hybrid approach allows teams to benefit from the ease of connectors for common scenarios while retaining the flexibility to extend the platform with company-specific integrations.

A custom connector is still a worker under the hood, but it is wrapped with metadata that makes it usable in a low-code way. This means business analysts or process designers can configure it in BPMN without needing to understand the implementation details. For example, if your organization uses a custom HR system that has no standard connector, you can build one with the SDK and make it available as easily as the built-in connectors.

When to Use Which

Workers and connectors both solve the problem of integrating processes with external systems, but the right choice depends on context, resources, and goals. Workers are the most flexible option.

If you are running large IT projects, have a team of developers, and sufficient budget, building custom workers or even custom connectors is often the best approach. This is the pro-code path. It allows full control, complex business logic, and integration with any system regardless of how unusual its API might be. For critical core processes, this level of reliability and customization is often worth the investment.

If your processes are less complex or less business-critical, or if you have a smaller IT team, low-code solutions are often more efficient. Connector templates are a good balance here. They standardize recurring API calls while making them easy for process designers to configure in the modeler. Protocol connectors like REST also fit into this category. They require some technical understanding of API calls but eliminate the need to maintain custom worker code. For many mid-sized organizations, this is the sweet spot that keeps projects moving without overloading developers.

Finally, there are scenarios where IT resources are very limited or even nonexistent. In such cases, out-of-the-box connectors become the primary tool. These connectors cover common needs such as sending emails, posting to Slack, or uploading to cloud storage. They allow business analysts or process owners to automate basic workflows without depending on development teams. While this approach comes with limitations in flexibility, it makes process automation accessible in environments where pro-code solutions are not feasible.

Looking Ahead

At this point, we have seen how processes can interact with external systems using workers and connectors. In the next part of the series, we will shift our focus from execution to monitoring. We will look at Operate, Camunda’s tool for observing running process instances, and see how it provides visibility into the state of workflows.

In the previous article, we looked at how to make a BPMN model executable and how to deploy it. Deployment in Camunda 8 is the point where a BPMN diagram stops being just a file and becomes a live process definition in the workflow engine.

In this article, we will look at what happens during a deployment, how Camunda 8 is structured internally, and why this architecture is modern and well-suited for today’s cloud-native systems.

What Happens During Deployment?

When a process model is deployed in Camunda 8, it is sent through the Gateway to the Zeebe cluster, where the engine manages the deployment. The Gateway forwards the request to the leader of partition 1, which serves as the cluster’s deployment authority. Zeebe parses and validates the BPMN XML, assigns a unique key and version, and writes the definition to the partition’s replicated event log. This ensures the model is stored reliably and remains available even if a broker fails. Each new deployment creates a separate version, allowing process definitions to evolve over time without interrupting running instances.

After the deployment is written to the log, the leader of partition 1 distributes the process definition to all other partition leaders. These leaders store the definition in memory so they can start new process instances locally without needing to retrieve the XML each time. This distribution ensures that every partition in the cluster can execute the latest process versions, while the actual deployment data remains safely persisted in the deployment partition.

This design keeps deployments fast, consistent, and fault-tolerant. By centralizing the persistence of definitions while sharing them across the cluster, Camunda 8 combines strong consistency with scalability. Every broker in the cluster can create process instances based on the latest deployed models, and if leadership changes within a partition, the new leader immediately has access to the definitions it needs to continue processing without disruption.

The Core of Camunda 8’s Architecture

At the center of Camunda 8 is Zeebe, a workflow engine that was built as a distributed system. Instead of relying on a single relational database, Zeebe uses an event log to persist every state change in a process. Each event, such as the creation of a task, an update of a variable, or the completion of an activity, is appended to the log. The current state of all workflows is reconstructed by replaying these events into an internal store. This approach ensures that the system can always recover its exact state, even after a failure, by replaying the log from the beginning.

Zeebe organizes execution across multiple brokers and partitions. A broker is a node in the cluster that manages workflow execution. The workflow space is divided into partitions, and each partition can host many process instances. Partitions are replicated across multiple brokers to ensure fail safety. One broker acts as the leader for a partition and processes commands, while followers replicate the data and are ready to take over if the leader fails. This replication strategy ensures that no workflow data is lost, even if a node in the cluster goes offline.

Scalability is achieved by adding more partitions and brokers to the cluster. This allows Zeebe to distribute workloads evenly and handle very large numbers of process instances in parallel. The system does not need to grow vertically by increasing the capacity of a single machine. Instead, it grows horizontally, which is a key characteristic of cloud-native architectures.

Zeebe itself is focused purely on orchestration. It creates jobs for service tasks and waits for external workers to claim and complete them. Workers connect through gRPC, subscribe to a task type, and fetch jobs when they are available. Once the work is done, the worker sends a completion signal back to Zeebe, which moves the process forward. Human tasks are managed in the same way: the engine creates the task, and Tasklist provides a user interface where people can complete it.

This design is inherently cloud-native. Zeebe is deployed as a set of containerized services, often orchestrated by Kubernetes. Brokers, gateways, and exporters can all be scaled independently, and replication ensures resilience against failures. By separating orchestration from execution, Camunda 8 avoids the limitations of monolithic systems and provides a flexible foundation for automation in modern distributed environments.

Surrounding Components

Camunda 8 is built as a modular platform around Zeebe. Operate provides a UI to inspect process instances, track progress, and resolve incidents. Tasklist is used for human tasks, allowing users to complete work assigned to them. Optimize offers analytics and reporting to identify trends and bottlenecks. These applications interact with Zeebe through exporters, which stream workflow data into dedicated storage that these tools can query efficiently.

For the vacation request process, Operate can be used to see the status of an individual request, Tasklist allows managers to approve or reject requests, and Optimize provides long-term statistics on approval times or rejection rates. Each component focuses on a specific use case, while Zeebe remains responsible for reliable orchestration in the background.

Why This Architecture Is Modern

Camunda 8 was designed for cloud-native environments from the start. Instead of embedding a workflow engine into a single application, Zeebe runs as a distributed service that can scale horizontally across clusters. It does not rely on a relational database but persists state in an event log, which enables strong consistency, replayability, and resilience in the face of failure.

This architecture aligns with how modern systems are built. It integrates through gRPC and REST APIs, works well in microservice landscapes, and can run on Kubernetes as a first-class citizen. By externalizing workers, Camunda avoids the pitfalls of monolithic BPM systems and instead embraces an orchestration model that coordinates distributed services, cloud APIs, and human interactions. This makes it particularly suited for organizations that want automation to grow alongside their digital platforms without being locked into rigid legacy tooling.

Looking Ahead

We now understand what happens during deployment in Camunda 8 and why its architecture is a strong fit for modern process automation. The next step is to look at how processes interact with external systems. In the following article, we will explore connectors and workers, comparing the built-in integration capabilities with the flexibility of custom implementations.

In the first part of this series, I showed why automation matters and why BPMN diagrams alone are not enough. The next logical step is to take a model like the vacation request process and prepare it for execution. While the diagram already describes the flow of activities, the engine requires more detail to understand how to run it.

This article explains what makes a process model executable, how variables and tasks are prepared for execution, and what happens when the process is deployed to Camunda. The vacation request process will again serve as the running example.

What Makes a Model Executable

A BPMN diagram that exists only for documentation does not need to care about data, system calls, or user interactions. For execution, these elements become essential. The model must specify which data is carried through the process, which steps are automated, and which require human input. Without this information, the engine cannot coordinate work.

In the vacation request example, the executable model needs to define the variables that represent the request itself: the employee’s identifier, the start date, the duration of the vacation, and the approval decision. Tasks such as “check vacation request” must be mapped to either a user task, where Camunda waits for manual input, or a service task, where an external system or worker completes the task automatically. This transformation from descriptive to executable turns the diagram into a precise technical specification.

Preparing for Execution

Execution in Camunda depends on process variables. Variables are the data elements that are moved through the process instance and act as input for task execution. They can be set, read or modified during the process execution.

Defining them carefully is crucial because they drive both the flow and the data exchange. For example, an exclusive gateway in BPMN routes the process based on the value of a variable. If the variable is missing or not set correctly, the process will fail at that point. The same applies to deadlines: a timer boundary event can read a variable that specifies how long a manager has to respond before the request is escalated. In this way, variables are not only containers of information but also control the logic of the process.

The following elements are used to capture and use variables in the process.

User Forms

User Forms are used to capture process variables through human interaction in a User Task. They can be used to start a process or to involve humans later in the process.

In the vacation request example, the process starts e.g. by capturing the employee’s ID, the start date and the duration of the vacation, and possibly the reason for the request. These values are stored as process variables, which means the engine can access them at any point in the process.

To achieve this, a form can be linked to a None Start Event by its key, and the Camunda engine will automatically show it in the assigned User Task in the task list.

User Tasks

User tasks are handled differently but follow the same principle of variable mapping. When the engine reaches a user task, it creates a pending task and makes selected variables available in a user form as well. In the vacation request process, the manager approval task needs to show the employee’s name, the requested dates, and any comments provided by the employee. These variables are explicitly mapped into the user task so the manager has the necessary context. When the manager completes the task, the approval decision is written back into the process as a variable, allowing the process to continue.

For this, the condition of each outgoing flow of an XOR gateway must be evaluated. The first flow resulting in a logical true will be taken. The expression approved is identical to approved=true and can be abbreviated.

Service Tasks

Service Tasks in Camunda require an external worker to perform the actual work. Workers are small Java programs that subscribe to specific task types.

In the vacation request process, an automated “Update HR System” step might be implemented by a worker that listens for tasks of type update-hr.

When the engine reaches this service task, it creates a job with the relevant variables. Those variables must be mapped into the task so the worker has all the information it needs, for example, employeeId, startDate and duration. The worker fetches the job, performs the update in the HR system, and signals completion back to the engine, possibly adding new variables such as updateStatus.

At this stage, the process model has all the necessary details for execution. Every task has a clear path to completion, either by a person or by a worker. Every decision point is based on well-defined variables, and variable mappings ensure that the right information is delivered where it is needed. The model is still the same BPMN diagram as before, but enriched with the technical details that make it executable.

Deployment in Camunda

Once the model is executable, it must be deployed to the engine. Deployment takes the BPMN XML file and registers it as a process definition. Camunda stores the definition, assigns it a version number, and makes it available for instantiation. Each deployment creates a new version, while existing process instances continue running on the version they were started with.

In practice, deployment can be done directly from the Camunda Modeler, via the REST API, or integrated into a automation pipeline. In the vacation request example, deployment means that the process definition is now available in the engine. From this point on, employees can start vacation requests as actual process instances, and the engine will manage their execution according to the model.

From Diagram to Running Process

The lifecycle of a process in Camunda moves from modeling to execution in clear stages. First, the BPMN diagram is made executable by defining variables, tasks, and assignments. Then the diagram is deployed, which registers it as a definition inside the engine. Finally, users or systems can start new process instances based on that definition.

In the vacation request scenario, one process definition controls all vacation requests. Each request submitted becomes an instance of that definition. The engine ensures that every instance follows the same flow, applies the same rules, and records the same data points. This consistency is the key difference between a diagram on paper and a process running in Camunda.

In my previous series on BPMN, I modeled a vacation request process and developed it step by step across several articles. Starting with a simple request and approval flow, I gradually added requirements such as manager decisions, HR involvement, and proper record updates. This made the process clearer, more realistic, and better aligned with how such a workflow is handled in practice.

That model provided a solid blueprint, but it remained a description on paper. Even though the diagram defined who should act and when, it could not guarantee that the process would actually run that way in reality.

This new series builds on that foundation. Instead of focusing on how to model processes, it explores what comes next: turning the model into an automated process in Camunda, where execution is reliable, traceable, and scalable.

The Gap Between Models and Reality

BPMN models are excellent for designing and communicating processes, but in practice they remain descriptive. A model tells people what should happen, but it cannot enforce that sequence. Employees may skip tasks, take shortcuts, or interpret responsibilities differently. This leads to processes being carried out inconsistently, even if the model is clear.

Manual execution also makes it hard to see what is happening in real time. A manager cannot easily check how many vacation requests are waiting for approval or whether a bottleneck has formed. Deviations from the intended process often go unnoticed until they cause delays or compliance problems. In regulated environments, this lack of transparency and control can quickly become a serious risk.

Why Automate?

Automation directly addresses these problems by making the process definition executable. When a model is deployed in Camunda, the engine ensures that every step is followed as defined. Tasks are routed to the right people or systems, deadlines can be enforced, and rules are applied consistently. This eliminates the risk of individual interpretation or skipped steps.

At the same time, automation provides full visibility into execution. Every process instance is tracked, making it possible to see progress, identify delays, and analyze performance. This transparency supports both daily operations and long-term improvement. Compliance also benefits, as every decision and transition is recorded and can be audited. Finally, automation scales effortlessly: whether the process runs ten or ten thousand times, the engine manages execution with the same reliability.

Camunda as the Bridge

Camunda is a process automation platform built on open standards like BPMN and DMN. It started as an embeddable workflow engine for Java applications, valued for its flexibility compared to traditional monolithic BPM suites. Over time, Camunda expanded with tools for task management, monitoring, and analytics.

With Camunda 8, the platform has become fully cloud-native. At its core is Zeebe, a distributed workflow engine designed for scalability and resilience in microservice and Kubernetes environments. Surrounding tools such as Operate, Tasklist, and Optimize provide monitoring, user interaction, and continuous improvement. This evolution reflects the shift from single embedded engines to distributed orchestration across people, systems, and cloud services.

Camunda provides the execution layer that connects BPMN models with automation. It takes a process definition and runs it as a real workflow, coordinating tasks between people, systems, and services. Instead of a static diagram, the process becomes a live entity managed by the engine.

The strength of Camunda lies in its flexibility. It is designed to integrate with existing systems rather than replace them. The engine is lightweight, can run in cloud or on-premise environments, and is suited both for small-scale deployments and large enterprise automation programs. This makes it a practical bridge between modeling and execution.

What to Expect in This Series

This first part has focused on why automation matters and why relying only on diagrams is not enough. In the next article, the focus shifts to what makes a BPMN model executable and how deploying it into Camunda turns it into a running process. Understanding that transition is key to making automation tangible.

The series as a whole will move step by step through the main building blocks of process automation with Camunda. After learning how to make and deploy executable models, we will explore the architecture of Camunda, understand how connectors and workers fit into the picture, and look at the tools Operate and Optimize for monitoring and continuous improvement.

Some Final Thoughts

A process model alone creates shared understanding. A process automation platform enforces that understanding in daily operations. This transformation is where the value of BPMN truly materializes, moving from theoretical design to measurable business impact.

Automation does not replace modeling but extends it. The combination of BPMN for design and Camunda for execution ensures that processes are not only well-documented but also reliably run and continuously improved.

Last time, you’ve learned about Business Transactions and how we can ensure, that all tasks in a transaction are executed or rolled back.

Today, I want to look into Signals, which are similar to Message Events, but more powerful. Let’s take a look.

The Kill Switch

The company decides, it wants to be able to cancel all ongoing vacation requests for a certain period in time. This way, they want to make sure, that all employees are present in the office to improve productivity.

Here are the requirements for our new process:

• Department Heads can signal a company-wide vacation block.

• If an active request is set for a certain period, it will be cancelled and the vacation days are added back to the employees account.

• If the request is outside of the period, we keep it running.

• Already approved requests are rolled back manually.

The model shows, how the model could look like. As usual, new elements are marked green.

The BPMN Building Blocks

Signal Start Event: “Cancellation Received”

• Signal Events can occur in different locations. They can be Start, End and Intermediate Events, and in case of an Event-Subprocess even non-interrupting (with a dashed border)

• Signal Events can have multiple recipients, in contrast to Messages, which are for one recipient only.

• In the example above, a single Signal “A” can start two processes A and B, and be received by all running instances of Subprocess C.

Author’s Note: Since an Event Subprocesses cannot cancel a parent scope, we use an Interrupting Message Start Event to cancel the parent execution. It means, the parent scope is cancelled immediately and the subprocess finishes, after informing the employee.

What’s Next?

We’re now have a second, very powerful, tool to react to events in our process landscape:

• Signals are meant for many receivers and are broadcasted without any receiver informations necessary, even over multiple instances of different processes.

• Messages are meant for a single process instance and need to be correlated with a certain process instance key.

This article closes my series about modeling with BPMN (for now). You’ve learned about the most common symbols in BPMN, what they mean and how you can use them to model your use cases.

Every process is different, so there is never the one right solution. Sometimes you’ll need workarounds and your models will get quite big, even if the problem you’re solving is quite easy. This is usually an indicator, that the processes do too much or are involved in too many systems. The process can help making it visible. And now that you see the process, you can also start improving it: Is this review step really necessary? Wouldn’t it be enough to just let employees just go on vacation?

I hope you enjoyed it and are now able to model your own processes.

Last time, I introduced you to Decision Tables, and showed you how more complex decision can be modeled, without bloating your process model.

Today, we take a look at an advanced topic, called transactions. It can happen, that we have a subset of similar tasks, that belong together. In case of an error, all of these tasks should be rolled back, some others not. For this, BPMN offers a Transaction Sub-Process. Let’s take a look.

The Weakest Link

Our IT landscape is changing rapidly. The company is introducing a brand new HR software to track vacation days. The old system is very buggy and no one is able to maintain it anymore. Errors have to be fixed manually, and data integrity is of highest priority.

Here are the requirements for our new process:

• Vacation days need to be updated in the new and the very old legacy system. The legacy system is very fragile, and errors have to be fixed manually.

• They need to be added to the company calendars as well, to ensure correct planning.

• In case of an error in the legacy system, all related systems have to be reset to their original state. Someone has to fix it manually.

The model below shows, how the model could look like. As usual, new elements are marked green.

To keep this example simple, I removed all the surrounding lanes and show only the one with the changed activities.

The BPMN Building Blocks

Transaction Sub-Process: “Update Vacation Days”

• Transaction Sub-Processes have a double solid outline. They group several tasks together and allow rollbacks of all contained tasks.

• Transactions are either cancelled, or terminated by an error, or successful if neither of the first two occur. A cancellation happens if a Cancel End Event is reached. A termination happens if an Error Event occurs, which is not handled inside the sub-process.

• A Cancel End Event has to be catched by an attached Cancel Boundary Event. It will trigger compensation and leave the sub-process at the boundary event. It is also possible to trigger compensation later in the process, for all successful activities in a Transaction Sub-Process.

• An unhandled error needs to be handled by an attached Error Boundary Event. In that case, no compensation is triggered.

Cancel End Event

• A Cancel End Event is an End Event with a solid, black X in the center.

• It can only be used inside of a Transaction Sub-Process. The cancel event must be handled with a Boundary Event attached to the sub-process.

Cancel Boundary Event

• A Cancel Boundary Event is (like all Boundary Events) a catching event, waiting for a cancellation to be thrown from the inside. It can only be attached to a Transaction Sub-Process.

• It will redirect the flow after a cancellation, and trigger compensation for all successfully executed tasks with a Compensation Boundary Event present.

What’s Next?

We’re now able to clean up parts of our system in case of errors or other events:

• We can group activities and ensure system integrity for a subset of tasks.

• Cancel End Events trigger compensation for the whole Transaction Sub-Process.

• Unhandled Error Events trigger no compensation.

In the next post I will introduce message broadcasting to multiple process instances using Signals.

Last time, I introduced you to the concept of compensation and how to rewind certain activities in a process.

Today, we take a look at improving our manual review process. Currently, the supervisor checks the workload of the employee manually, and decides if the employee can go on vacation, based on the number of their open tasks.

This works fine, but honestly, we want our supervisor to work on more important tasks, like improving employee satisfaction or improve productivity instead of manually checking on their peers.

Let’s take a look at a concept called Decision Tables.

Work Smart, Not Hard!

Here are the requirements for our new process:

• Supervisors don’t have time to check each workload individually. There is a service endpoint, that returns the number of open tasks of an employee.

• We can use static rules to decide if a request must be rejected:

  • Requests,

    • for > 20 days are rejected.

    • with no open tasks are approved.

    • with 1-5 tasks are approved, if requested days are less or equal 10.

    • with 1-10 tasks are approved, if requested days are less or equal 5.

    • everything else is rejected.

The model below shows, how the model could look like. As usual, new elements are marked green.

The Decision Table behind the new Business Rule Task is shown below.

The BPMN Building Blocks

Business Rule Task: “Check Workload”

• Business Rule Tasks are a way to automate more complex decision logic.

• They use a Decision Table modeled with DMN (Decision Model and Notation) which is another standard in the world of business process management.

• The task has static rules (e.g. when # of requested days > 10) and applies them to the provided inputs (open tasks and requested days). It generates an output (approval=false) based on the rules that apply for the input.

Decision Tables

Here is the Decision Table, I created for the provided vacation rules:

• A Decision Tables is used to generate an output (a decision) based on inputs and a set of static business rules. The rows are evaluated one by one, starting with the first.

• It has the advantage of a readable format, that can be easily created e.g. by analysts who work with spreadsheets.

• Each row contains a set of inputs, rules and outputs. If the rules match, the row has a match or a hit.

• The rules in each table can be overlapping, leading to multiple hits. Therefore a Hit Policy is used to decide how to collect the matching outputs. In our example, the first hit will be returned.

What’s Next?

Decisions just got way smarter:

• Decision Tables allow us to formulate complex rules in a readable form, instead of using multiple XOR gateways.

• Companies use tables spanning from many hundreds rows to over a hundred thousand decision rows.

• They’re modeled using the DMN standard. It offers even more sophisticated ways, to model decision. But this is content for another post.

In the next post, I want to dig a bit deeper into compensation, and show you how to achieve some kind of transactional behavior, by grouping a set of activities together. The special thing about this is, that they either all succeed as a group or completely fail together.

Last time, I introduced a way to react to external events in your process with an Event-based Gateway. The process flow waits at the gateway, until an event happens, and takes the outgoing flow where the event occurs. This could be an intermediate message, a timer or any another incoming event.

Today, I want to show you, how a process can be rolled back, in case of an event or an error. BPMN has a concept called compensation, which makes it possible, to roll back already executed activities.

Your Flight Has Been Cancelled

Here are the requirements for our new process:

• Employees are able to cancel their request, no matter how far the process is.

• It has to be ensured, that–in case of a cancellation–the amount of vacation days is unchanged.

The model below shows, how the model could look like. As usual, new elements are marked green.

To keep the Compensation scenario simple, I moved the HR participant back into the original pool. Compensations over multiple pools are a bit more complex, since only Message and Signal Events can be sent between different pools.

The BPMN Building Blocks

Event Sub-Process: “Cancel Request”

• Event Sub-Processes have a dotted outline, and can be modeled in any process or sub-process. They have a single Start Event which can both be interrupting or non-interrupting. It has to be an event though.

• They’re used to listen to (mostly external) events, that can happen at any time during process execution, but which are important for our process. In our case, e.g. we could receive a cancellation at any given time in the process. Note that I used an Interrupting Message Event as start. That means, that the parent process is interrupted in its execution, when a cancellation comes in.

• An Event Sub-Process can be activated multiple times (if non-interrupting) as long as the parent process is active.

• You cannot add Boundary Events to it, since the Event Sub-Process itself, acts like a Boundary Event to the process it is placed in. The difference is, while a Boundary Event leaves the scope it is attached to in case of an event, the Event Sub-Process stays inside the scope where the event happens.

Compensation Throw Event: “Reinstate Vacation Days”

• An Intermediate Compensation Throw Event is used, to trigger compensation in the current process. Since it is an Intermediate Event, it has a double, solid border and since it is Throwing, the rewind symbol (you might know this from your cassette player or VCR) is solid black.

• Compensation is not done automatically. Your process needs to have counter activities for all tasks that you want to “rewind”.

• Compensation can only happen inside of a pool. This is a main difference to messages or signals, which can have one or multiple recipients in other pools as well.

Compensation Boundary Event

• A Compensation Boundary Event is one way to catch a compensation and execute a counter measure for the task it is attached to. You can also use a Compensation Start Event in an Event Sub-Process to catch a compensation event.

• Compensation is only triggered, if its activity has successfully completed. Otherwise it will be ignored.

Compensation Task Marker

• The compensation action is e.g. a Service Task. It has a little rewind symbol in the bottom left corner and must implement the logic to rewind the previous task.

• It is connected to the Compensation Boundary event via an Association. That is a dotted line with an arrow on the target side. It’s not a regular process flow, but associates the compensation action with the original task. That also means, that the compensation Task has no outgoing flows.

What’s Next?

We now are able to clean up our system in case of errors or any other event:

• We can listen to outside events with Event Sub-Processes, which can either interrupt the parent process, or keep it running.

• Compensation Events can roll back any changes that we made in other systems.

In the next post, we want to automate the review process a bit more. I will show you, how more complex decisions can be modeled, without making the model complex.

Last time, we learned how we can react to errors of automated tasks. I introduced different Error Events to you and introduced you to the concept of a Service Task, which is executed by a system, without human interaction.

Today, I want to improve the customer experience of our process. Imagine you just handed in your next vacation request. You hit the Send button and realize, that you requested too few days. That trip to Canada takes 14 days, not just four.

In the current process, you’d need to call HR, or your supervisor, and ask for a rejection, so you can send another request. That is possible, but not very smart. Let’s see, if there are better ways to do that.

Give Employees Some Flexibility

Here are the requirements for our new process:

• Employees receive an informal mail about their vacation request. The e-mail contains a link to a form, to modify the request.

• They can update their vacation request for the next two hours after submitting them. The request will be processed afterwards.

The model below shows, how the model could look like. As usual, new elements are marked green.

There’s a fancy new Gateway and it has something to do with our two hour window to change the request. Do you have an idea what it exactly does?

The BPMN Building Blocks

Timer Intermediate Catch Event: “Time Is Ticking”

• A Timer Intermediate Event is used to halt the process for a certain amount of time.

• Timers are always Catch Events, since they measure time and catch the event when time’s up or a certain date is reached.

Message Intermediate Catch Event: “You’ve Got Mail“

• A Message Intermediate Catch Event is used to halt the process to wait for a certain type of message. As you already learned, it is catching therefore the symbol is empty with black border.

• The difference to the Timer Event is, that a message is not guaranteed to arrive. A timer will come to an end sooner or later. In our case, the employee sends a correction of the request, or not.

Event-based Gateway: “Let’s Go Where The Action Is“

Some of you might relate to that: It’s Friday and you have several invitations to parties. But which one should you pick? Event-based Gateways face a similar issue, but they come with an easy solution: First come, first serve.

• Event-based Gateways are a way to steer your process flow to where the action is. It will not evaluate conditions, but takes the outgoing path, where the earliest events happens.

• To achieve this, only catching events are allowed after the Gateway. This includes Intermediate Timer Catch Events, Intermediate Message Catch Events (or a Receive Task), Intermediate Conditional Catch Events or Intermediate Signal Catch Events.

• Conditional Events (with the small document) happen if a certain condition evaluates to true. Signal Events (with the small triangle) are similar to Message Events. The difference is, that a Signal Event is a broadcast to all processes listening to it. Message Events are meant for one recipient only.

• Note, that Error Catch Events are NOT allowed. They are Boundary Events only.

What’s Next?

The employee is happy. They were able to correct their request and get their approval just in time.

• We use an Event-based Gateway to wait for certain events, and continue where the first event occurs.

• We added a Timer Event, to ensure that the process continues after a certain time.

• Not every Catch Event is automatically an Intermediate Catch Event. Errors (and some other symbols) can only be used as a Boundary Event.

If you think about it, it makes sense. Errors happen in a certain context, e.g. during a certain Task or Sub-Process. We want to handle them right there, in this context. The process flow must not wait for an error to continue.

In the next post we want improve the user experience a bit further, by allowing employees to cancel requests and ensuring, that booked vacation days are added back with a mechanism called compensation.

Last time, we learned to keep our process model simple by embedding processes into a Sub-Process, or use a Call Activity to reference an external model. In this article I want to highlight, how errors can be handled and how different semantics can lead to totally different process models.

Handle The Errors That You Know

Here are the requirements for our new process:

• Vacation day checks are now automated by a service.

• If the remaining vacation days are insufficient for the request, it will be rejected automatically.

• Our HR API returns an error, if the amount of requested days is higher than the remaining days.

The model below shows, how the model could look like. As usual, new elements are marked green.

Note: I keep the Sub-Process for visualization reasons, even though I said that Call Activities would be the way to go to prevent duplication.

The BPMN Building Blocks

Error Boundary Event (Interrupting)

• Error Boundary Events are used to catch errors and diverge the process flow to an alternative path. Just like all Boundary Events, it has a solid, double border. Inside the event is a small, empty lightning symbol. This means it is catching an error.

• It can be attached to every kind of Task or Sub-Process.

• Error Events can only be used as Error Start Events in an Event Sub-Process (which we will deal with later), or Error Boundary Events to catch errors, or Error End Events to throw errors. They are always interrupting.

Service Task: “Check Leftover Vacation Days”

• Service Tasks symbolize a task that is automated by a system. There is no human interaction necessary. The task has two small gears in the upper left corner.

• The tech behind it could be anything. An AI agent, a program writing data to a database, or some other API.

Many Roads Lead to Rome

There are of course other ways to solve the vacation day issue. One could argue that it is not an error, but we could just read the number of left over vacation days, do some math on the numbers, and use an Exclusive Gateway to continue, based on the result:

It depends on the semantics: Is it an error if someone requests more days than available? In our case it is an error, since the API returns an error when called with an invalid amount of vacation days. It could also be, that in your case it is just not, and your API returns something else.

What’s Next?

Our model just got automated, and we are listening to errors that might occur:

• When to few vacation days are available, we use an error to diverge the flow into a rejection.

• We also learned that there are many ways to solve a certain issue. It all depends on the semantics of your process.

In the next post we want improve the user experience a bit, by allowing employees to change their mind.

Last time, we added some escalation events to our model, to keep the process afloat. In this article I want to dive into keeping models simple and the reusability of components, by using sub-processes of different kinds.

Imagine, the review task for supervisors and the department heads, get more complicated. We would need to model the logic twice: once for the supervisor and once for the department head. That would be unnecessary. BPMN offers a construct called a sub-process, to address this. Let’s take a look.

Note: Keep It Simple, Stupid! The idea of K.I.S.S. is that solutions work best and are easier to understand, maintain, and improve when they are kept as simple as possible.1

Reuse Process Logic With a Sub-Process

Here are the requirements for our new process:

• Before an employee can go on vacation, the leftover vacation days have to be checked.

• Additionally, the supervisor or department head has to check the current work balance. The company hates, if work isn’t finished before vacation.

The model below shows, how the model could look like. As usual, new elements are marked green.

Since the review logic is now slightly more complex, we don’t want to duplicate it, since changes need to happen in both paths. I used two different methods to encapsulate a process: a simple Sub-Process on top where a regular process is modeled and a Call Activity below, which is just a reference to an external process definition. Both encapsulate a process.

Note: The Sub-Process is only used as visual aid. It doesn’t help to reduce duplication. For that use case, both review tasks need to be Call Activities.

The BPMN Building Blocks

Parallel Gateway: Multitasking

• Parallel Gateways are a diamond shape with a plus sign in it. They are used to split a single flow into multiple outgoing flows, without any condition. All outgoing path will be taken.

• When merging different paths with a Parallel Gateway, it waits until all incoming flows reach it, basically synchronizing the process back into a single outgoing flow.

• The Parallel Gateway is also called AND Gateway, because of its semantics of following or waiting for all (the first AND the second AND the third etc.) outgoing or incoming paths.

Sub-Process: “Review Request”

• Sub-Processes are part of a bigger model and visually separate different logic. It is a simple box with a solid border. If it is collapsed for readability, there is a small plus (+) sign at the bottom.

• It can be used to simplify a model, but doesn’t help when it comes to duplication. A Sub-Process cannot be referenced.

Call Activity: “Review Request”

• Call Activities on the other hand are a reference to an external process model. They have a bold solid border with a plus sign (+) on the bottom. There is no expanded visualization for Call Activities.

• When a Call Activity is reached, a new instance of the external process is started.

• This way, we can reuse a process model in different other processes, without the need to copy it.

What’s Next?

Now we know how to keep our process model clean:

• Sub-Processes can be used to encapsulate a process. They can be collapsed into a Task to keep the model simple.

• Call Activities are a way to reuse a process in different models.

• Both support Boundary Events, to react to events.

Errors can happen everywhere and also BPMN offers mechanisms to handle them. A stopped process is even worse than a waiting process. Someone has to fix the issue manually. In the next post we will learn about errors and how they can be used to keep a process running, even though errors happen.

Last time, we improved our process model to enable communication between different pools in your organization. Today I want to improve the quality of our process.

Imagine the supervisor of an employee is on vacation. All vacation approvals are now in a waiting state, since no one is there to handle them. Isn’t there a way to improve this? Sure! Let’s take a look.

Adding Escalation to Our Process

Here’s a solution to our absence scenario:

• Vacation requests have to be processed within 1 day.

• If it takes longer, the supervisor gets a friendly reminder.

• If it takes longer than 4 days (in case there is a weekend in between), we delegate the task to the department head.

The model below shows, how the model could look like. As usual, new elements are marked green.

Now, there are two new elements attached to the manual task, indicating some time restrictions. They lead to follow-up tasks for the supervisor and the department head. Let’s look at them one by one.

The BPMN Building Blocks

Escalation Boundary Event (Interrupting)

• Boundary Events are a type of Intermediate Events (with a double solid border) which means, they are neither Start nor End Events.

• They are always catching (not throwing) events. They are triggered by an event thrown during the execution of the task they’re attached to, and have an outgoing flow.

• If it catches the event, the task is interrupted. The task is no longer active and outgoing flows from the task are cancelled.

• Escalations are used to escalate the flow to a higher instance, if certain constraints are not met. In our case we escalate the flow, when a vacation request is not reviewed after 4 days.

Timer Boundary Event (Non-Interrupting)

• A Boundary Event can also be non-interrupting. This means, that in case the event is caught, the task it is attached to, continues. This also means, that there can be two active flows. One for the finished task, and one for the boundary event.

• Timers are used to wait for a certain amount of time. In our case, the timer creates an event after 1 day. This event has no further semantic meaning. It just signals that a certain amount of time has passed.

What’s Next?

Now we have the possibility to react to time semantics:

• It is ensured that a process only waits for a certain amount of time.

• We use non-interrupting semantics for reminders, with the goal to continue the process flow.

• We use interrupting semantic to cancel a task and take another route.

Now that we ensure that the flow continues in a timely manner, we can take a look at the details of our review process. A review can contain of many different steps.

In the next post we will learn about sub-processes and how they can group functionality and keep complex models simple.

Last time I showed you, how you can make responsibilities transparent in a process, using a Pool with different Lanes. Every participant got their own lane, with all the tasks they’re responsible for.

Imagine you have more than one process participant, which requires you to add an additional pool. In our example this could mean, that HR is an external process participant. BPMN offers a mechanism to communicate between pools, with other process instances: Messages. Let’s take a look.

Adding More Participants to Our Process

Here’s the scenario:

• HR has their own process to handle approved vacation requests.

• We inform HR with a message, that we approved a vacation request.

• A new process is started, to handle the update in the HR system.

The model below shows, how the model could look like. As usual, new elements are marked as green.

This approach decouples the two processes from each other. The HR process is only started, if a message arrives. The review process can finish as soon as the message has been sent. No need to wait for HR.

The BPMN Building Blocks

Send Task: “Inform HR”

• Both the Send Task and the Intermediate Message Throw Event are used to trigger a message. It can be a message to another system, to a task or even a user.

• Intermediate Events are events that are neither Start nor End Events, but events that happen during the process execution. They have a double solid border. If they produce an event, the symbol is solid black.

• A message is not a broadcast. There is exactly one recipient of this message.

Message Start Event: “Request Approved”

• A Message Start Event is a smarter version of the None Start Event. It waits for a certain message and starts the process.

• Since it is a receiving event, the symbol is not solid black, but has only a solid, black outline.

• There are only catching Start Events. They always wait for an external trigger to start the process or sub-process.

Message Flows: Connecting Pools

• A Message Flow has a dashed line with a dot on the starting side and an empty triangle on the destination side.

• They signal the communication between two Pools. They are used to connect a message send + receive pair, or two pools, or a mix of both.

What’s Next?

Now our model starts to get quite big:

• We defined the way, how different participants in a process can collaborate between different pools.

• We also learned how we can decouple processes, and let them communicate asynchronously with messages.

Now that we painted a clearer picture of our organization and how we communicate in it, we can take a look at the review process. What happens if the supervisor is also on vacation? The process will wait, even if the vacation of the employee is starting soon…

In the next post we will learn about some escalation mechanisms, to ensure that a process is always able to continue.

Previous Posts of This Series

Maturity models are frameworks that help organizations assess their current capabilities in a specific domain and understand the steps needed to improve.

They break down complex areas like process management, software development, or orchestration into clear levels of progression, from ad-hoc or initial practices to optimized and innovative approaches.

With this article, I want to give you a quick overview of the most common models when it comes to Business Process Management. I’ll follow up with a more detailed post about each model and how they look like in real-life.

Capability Maturity Model Integration (CMMI)

💭 How Well Do We Build and Deliver Capabilities/Products?

Developed in the 1990s by the Software Engineering Institute (SEI) at Carnegie Mellon University, CMM (and later CMMI) was originally designed to assess and improve software and systems engineering processes, helping organizations consistently develop and deliver high-quality products and services.

Source: https://www.cmmiinstitute.com/learning/appraisals/levels

Focus: Measures process capability and performance, mainly in engineering and product/service delivery.

Goal: Enables organizations to develop, deliver, and maintain high-quality products and services consistently and efficiently by improving their capability maturity.

Example: Projects with very low maturity often get delayed or are over budget, while a high maturity allow projects to be measured and improved e.g. based on defined KPIs.

Business Process Management Maturity (BPMM)

💭 How Well Do We Manage, Measure, and Improve Our Business Processes?

Created in the 2000s by the Object Management Group (OMG), BPMM was designed to provide organizations with a framework to assess and improve the maturity of their business process management practices across industries, promoting standardization, measurement, and continuous improvement. CMMI had a big influence on its development.

BPMM can be mapped to CMMI “but [it] has been written to guide improvement of business processes, which tend to be more transactional and are better characterized as workflows across organizational boundaries rather than the more bounded project orientation of CMMI”1

Source: https://www.omg.org/spec/BPMM/1.0/About-BPMM

Focus: Measures process management governance, standardization, and improvement across the whole business.

Goal: Helps organizations achieve predictable, standardized, and continuously improving business processes that align with strategic goals.

Example: Low maturity means lots of manual work, without any process management, whereas a high maturity reflects organization wide usage of process management and improvement.

Process Orchestration Maturity Model (POMM)

💭 How Well Do We Orchestrate, Automate, and Scale Processes Across People and Technology?

Introduced by Camunda in the 2020s, the Process Orchestration Maturity Model was created to help organizations evaluate and improve their ability to orchestrate processes effectively across people, systems, and automation, focusing on scaling orchestration efforts to drive business outcomes.

Source: https://camunda.com/process-orchestration/maturity

Focus: Measures orchestration capabilities, evaluating strategy, structure, measurement, and tech adoption specifically for process orchestration.

Goal: Guides organizations in achieving effective, scalable process orchestration that delivers measurable business outcomes across people, systems, and automation.

Example: Low maturity means, there might be no or only minimal, siloed efforts to orchestrate, but not in a central or coordinated way. A high maturity, on the other hand, is giving organizations the ability to deploy process orchestration at scale across the entire company.

The Bottom Line

By using maturity models, organizations can benchmark themselves, identify gaps, set realistic improvement goals, and track their progress over time.

But most importantly: These models are not competing.

CMMI laid the foundation by focusing on capability development in software and systems engineering. BPMM expanded this approach to cover enterprise-wide business process maturity. POMM, in turn, focuses on a specialized area within BPM, evaluating and improving an organization’s process orchestration capabilities.

Stay tuned for more detailed articles about maturity models and how companies can apply them!

In the last post, we added the possibility for alternative paths in a process. A person is able to decide if a vacation request is approved or rejected. The process stated clearly what has to be done, but it lacked clarity about who is responsible for which task.

While a supervisor is responsible for the vacation requests approval, they might not be responsible to do changes in the HR system. BPMN offers a possibility to do just that. Let’s take a look.

Dividing a Process Into Separate Lanes

By dividing your process into separate lanes, and assigning different parties to each lane, we are able to place tasks into them, giving the process an additional layer of clarity:

• The Employee is the initiator of the process.

• The Supervisor is responsible to review the process, make a decision and inform the employee about a rejection.

• HR is responsible to update their system.

The model below shows, how the process looks like with a responsibility model.

Each lane represents another participant in our vacation process, so everyone is on the same page on who does what.

The BPMN Building Blocks

Pools

• A Pool represents a participant in a process.

• It can be an organization, a department or even an external entity.

• Pools can also be collapsed, if the process inside is unknown or not relevant.

Lanes

• Lanes are subdivisions in a pool.

• They’re used to visibly organize and structure the tasks inside of a pool.

What’s Next?

Now we have added some more organizational information to make our process clearer:

• All participants of the process know, which tasks are their responsibility.

• They also can see dependencies related to their tasks.

Imagine now, that we have multiple departments, all with their own vacation process. The HR department could also be modeled in a separate pool. But how is it possible to communicate between different pools?

In the next post, we will learn about communication between different entities, even if they are not in the same pool. For that, I will introduce message events and message flows.