Camunda BPMN

Camunda is a workflow and decision automation platform built around BPMN 2.0. In my stack it is the enterprise-grade counterpart to n8n: where n8n shines at fast, visual API automation, Camunda excels at governed, long-running, stateful processes.

I model business processes as BPMN diagrams where routing, timers, events, and human task assignments are explicit. This turns complex workflows and their boundaries into something stakeholders can read — and developers can instrument.

It pairs naturally with my DDD background: each process instance is an aggregate lifecycle, and BPMN becomes the executable map of the domain, with monitoring, metrics, and versioning built in.

The modelling and execution gap is where most teams stumble, and I close it deliberately. A diagram only matters if the engine executes exactly what it shows — so I keep the BPMN as the single source of truth, with service tasks wired to real application code and message/timer events driving state transitions.

For long-running processes Camunda ships the hard parts I would otherwise build by hand: durable process state, timers, retries on failed task executions, incident handling, and compensation paths. That removes an entire class of "we lost the state machine" problems.

Human task management is a first-class concern. I model manual steps with form data, assignment rules, and deadlines, so the platform knows exactly who must act and what happens when they do not — which turns SLA-driven processes into explicit, monitored workflows rather than folklore.

DMN decision tables sit alongside orchestration for rules and policies. I use them where business rules change more often than code — pricing, approval thresholds, eligibility — so analysts can maintain logic without a deploy cycle.

Monitoring came from the engine, not from scraping logs. Process metrics, defined KPIs, and the Operate dashboard show where work is stuck, what failed, and how often each variant runs, so improvement is evidence-driven.

I pair Camunda with event-driven integration: process instances publish events to the wider system (outbox, queues, event store) and react to incoming events. That keeps the workflow engine honest about state while the rest of the architecture stays event-sourced and decoupled.

I model process boundaries before I model the flow. I start by naming the start and end of the process and the states it moves through, so the BPMN becomes a faithful map of a real workflow rather than a diagram that looks right but means little.

The diagram is the running system, not documentation. I wire service tasks to real application code, message events to actual messages, and timers to real deadlines — so stakeholders review the same model the engine executes.

Long-running state is the engine's job. I let Camunda own process instance state, timers, and incident handling rather than hand-rolling a state machine in code, which removes an entire class of "lost state" bugs.

Human tasks get form data, assignment, and a deadline. I model the manual step with what the user must see and do, plus a handling rule — so the platform knows who must act and what happens when they do not.

DMN decision tables capture rules that change often. Pricing, thresholds, and eligibility live as analyst-maintainable tables instead of code, so policy changes land without a deploy cycle.

Every process emits events outward and reacts to events inward. I wire the engine to the wider event-driven system via outbox and queues, keeping process state consistent without making Camunda the whole architecture.

Monitoring is designed in from the start. Process KPIs, stuck-instance visibility, and the Operate dashboard are configured early, so improvements to the flow are driven by evidence rather than instinct.

I keep diagrams human-sized. When a process gets long I decompose into sub-processes and call activities, so each diagram stays readable and the whole process stays reviewable.

Compensation paths are explicit. Where a later step must undo an earlier one, I model that boundary explicitly — because long-running business processes rarely finish cleanly on the first attempt.