BPMN process development: where orchestration breaks
BPMN process development almost never breaks at the stage of drawing the diagram — it breaks at the junctions.
Approval moves from CRM to billing, from there to the warehouse system, and at every handoff someone manually reconciles statuses, because the integration is "temporarily" done via a file export.
While the volume of requests is small, this goes unnoticed; as the flow grows, tasks pile up in the queue, approval deadlines slip, and business process orchestration turns into a set of disconnected steps.
The most costly failure is one in the middle of the process.
If the state of a process instance lives in the application's RAM or in an intermediate table without a journal, a node crash means not "retry the step" but "figure out where it stopped." The request hangs in the "processing" status, the assignee does not receive the task, and the client gets no answer.
Recovery takes hours of manual reconciliation, and every such case undermines trust in approval automation as a whole.
The second hidden problem is the lack of visibility into process bottlenecks.
When the stages are described only in a paper regulation, and the actual movement of requests is visible only in application logs, it is impossible to answer a simple question: which step is holding up the flow.
Process bottlenecks are identified only after deadlines have already been missed, not in advance based on metrics.
We break down how this is addressed: where an engine with state persistence and an event journal is needed, how transaction boundaries between services are built, and what process observability at every step provides.
What BPMN engine orchestration delivers: the effect in metrics
Where the measurable effect appears
Process orchestration moves approval logic out of chats and spreadsheets into an executable diagram: the BPMN engine drives the process instance along a defined route, calls services itself, and sets timers and escalations.
Process cycle time shrinks not by "making people faster" but by eliminating idle time between steps — a request no longer waits to be forwarded by hand.
Step automation delivers a second effect — predictability. Data validation, calculation, and calls to an external system run as service tasks with a fixed outcome, while only decisions that require a human remain manual.
The share of manual operations drops, and with it goes the class of failures like "the request got lost," "we forgot to come back to it," and "it was approved twice."
Monitoring as a source of metrics
Process monitoring is built on the same events as execution: for each instance you can see which step it is on, how long it has been sitting there, and where a queue is piling up.
The bottleneck is found from data, not from gut feeling — and it is a specific transition that gets optimized, not the entire process.
| Launch option | When it fits | Limitations |
|---|---|---|
| Synchronous call | Short operations with an instant response | Blocks the thread during external delays |
| Asynchronous queue | Long steps, external integrations | Requires retry handling |
| On a schedule | Scheduled reconciliations, reports | Delay between the event and the start |
| On an event from a system | Reaction to a user action | Requires a reliable event source |
The choice of mode also determines the failure profile: a synchronous launch is sensitive to an external system being unavailable, while an asynchronous one is sensitive to duplicates and message ordering. We design the route with this in mind from the start.
Camunda provides an executable diagram and an instance log in a single loop — it shows both the current state and the history for incident analysis.
How we implement BPMN processes: stages of engineering work
BPMN implementation starts not with drawing diagrams, but with a process audit: which steps are already automated, where data is transferred manually, which systems participate in the chain.
At this stage we identify bottlenecks — approvals by email, duplicated statuses across different systems, manual transfer of data between the accounting system and the CRM. The audit produces a map of the actual process, not the one described in the policy.
Next comes designing the process diagram and configuring orchestration. We describe the process in BPMN notation, define executor roles, branching points, timers, and error handling, while the process engine links the steps to your services via API and message queues.
Each step gets an owner, a deadline, and a transition condition — the process stops depending on whether an employee remembers what to do next.
- Process audit. We analyze the current chains, participants, and systems, and identify manual operations and data loss points.
- Approval of the target diagram. We show the customer the process map before implementation — where steps are reduced, who approves, and what goes to automation.
- Designing the BPMN model. We describe pools, lanes, gateways, timers, and boundary events; the diagram remains readable for the business, not just for the developer.
- Configuring orchestration. We connect the engine to your services, set up queues, retries, and failure handling at each step.
- Testing scenarios. We run both standard and emergency branches: external service failure, approval timeout, cancellation of a request mid-process.
- Monitoring and metrics. We display on a dashboard the duration of each step, the share of requests with manual intervention, and the number of failures — bottlenecks are visible without digging through logs.
- Handover of documentation. We provide process diagrams, integration descriptions, administrator instructions, and a change policy.
After handover, the process lives without us: a new branch or participant is added by editing the diagram, not by rewriting code. If you have a chain that is due to be taken out of manual mode, describe the task, and we will come back with an estimate and a work plan.
How does orchestration differ from choreography in BPMN?
Orchestration is when there is a central coordinator: a single executable process in a BPMN engine holds all the logic, calls services in sequence, waits for responses, handles errors, and decides where to go next.
For it, all participants are "black boxes" with a clear contract: it received a task and returned a result. Choreography works differently: there is no central controller, and each participant knows on its own which event to react to and which event to emit.
The scenario logic is spread across services, and to understand the entire order path, you need to assemble the picture from their behavior.
The difference shows up in the cost of changes. In orchestration, a new step is an edit to one diagram: you added a task, moved a gateway, changed a condition.
In choreography, the same step requires agreeing on who publishes an event and when, and updating several services in sync — otherwise the scenario will stall halfway.
On the other hand, choreography provides loose coupling: services do not know about each other, and the coordinator does not become a single point of failure or turn into a load bottleneck.
Hence the rule for choosing. Orchestration is chosen when the scenario is long, with branches, timers, compensations, and a requirement to see the status of each instance in one place — contract approval, onboarding, request processing.
Choreography — when the steps are short, there are many participants, and they belong to different teams, and strict sequencing is not needed: sending notifications, updating reference data, reacting to events.
In practice, pure designs are almost never found. The working option is orchestration within a single business domain, where control and monitoring are needed, and distributed events at the boundaries between domains.
This way, the central coordinator is responsible for its own area rather than the entire landscape, and the architecture does not become more complex ahead of time.
Case: reducing manual operations in the approval process
The approval process for service connection requests ran through email and spreadsheets: a request reached the manager, who manually determined the approvers by contract type and amount, forwarded it onward, and reminded people about it in chat.
Of the six steps on the route, three were manual, the average completion time was 4 business days, and about 12% of requests got stuck — the approver went on vacation or missed the email, and the request simply sat there without moving.
What was changed
The route was moved into an executable BPMN process: the branching by contract type and amount threshold was described as gateways, instead of forwarding emails — tasks in the approver's personal dashboard, instead of reminders — timers on the boundaries of user tasks.
If the approver does not respond within the allotted window, the process itself raises a task to their manager rather than waiting for a manual nudge.
A rejection returns the request to the initiator with a mandatory comment — the reason for rejection is recorded in the process instance history rather than getting lost in the correspondence.
What the result was
Manual steps went from three to two: the initiator fills out the request, the approver makes a decision. Route determination, reminders, and escalations were taken over by the engine.
The average completion time dropped from 4 business days to 9 hours, and the share of stuck requests fell from 12% to zero — timers do not let an instance remain without an owner.
Rejections for the reason "the request was lost" disappeared as a category: every instance is visible in monitoring with its status and current assignee.
| Metric | Before | After |
|---|---|---|
| Manual steps on the route | 3 | 2 |
| Average completion time | 4 business days | 9 hours |
| Stuck requests | 12% | 0% |
The orchestration engine is Camunda: it provides an executable model, instance history, and a monitoring dashboard that shows at which step requests are piling up. This makes it possible to change the route by editing the diagram rather than rewriting code.
Compatibility, migration, and rollback: technical concerns
What will happen to processes that are already running in another system?
We transfer not a picture, but an executable model: the schema, role bindings, task handlers, and routing rules. First, we capture the current logic and record it as a diagram, then migrate process by process with the old and new environments running in parallel.
Until the new version is validated on real data, the old one remains primary — the switchover happens process by process, not "all at once."
What if a rollback is needed? Model versioning handles this without rewriting code: the version pointed to by the deployment remains active, while the new one runs on a limited group of requests.
If the metrics drop, we revert to the previous version; already running instances finish according to their own rules, and nothing "hangs" midway.
What about access? We describe roles and permissions separately from process logic: who starts, who approves, who sees the history. This allows changing the set of participants without modifying the schema itself.
Integration with current systems is done through service calls and queues — the accounting system, portal, email, and document storage stay in place; the process merely orchestrates the steps between them.
The customer receives:
- process diagrams with a description of steps, roles, and approval points;
- configured deployments and model versioning rules;
- an access and role matrix with mappings to participants;
- a description of integrations: which systems are called and at what point;
- a rollback procedure to the previous process version;
- process documentation and a maintenance guide.
Describe your task — we will come back with an estimate and a migration plan.
Timelines for BPMN Process Implementation Stages
Timelines depend not on the number of diagrams, but on the number of external systems involved in the process. A process confined within a single service and a process that calls billing, warehouse, and a mail gateway differ in effort by orders of magnitude.
Below are reference points for a typical landscape with 2-3 integrations; after the audit, the ranges narrow down to specific values.
The stages overlap: designing the next diagram starts while the previous one is still being tested. Therefore, the total timeline for launching the first phase is 2-3 months, not the sum of the table rows.
After that, each new diagram in an already configured landscape takes less time: infrastructure and connectors are reused.
Two factors influence timelines the most — the readiness of external systems to emit events and the speed at which the business approves the diagrams. If the process owner is available and decisions are made during the meeting, design fits within the lower bound. If the regulations have to be reconstructed from email threads, the audit stage stretches out.
Describe your process and the list of systems it must work with — we will get back to you with a stage-by-stage estimate and a launch plan.
Compatibility with the customer's existing infrastructure
Developing BPMN processes with Camunda does not require migrating to someone else's stack: the engine is deployed alongside your systems, and the process communicates with them through the same interfaces already used in the environment. We verify system compatibility at the start — before designing the diagram, not after.
We separately check infrastructure constraints: available ports, outbound connection policy, limits on attachment size and history depth.
We design service connections so that the unavailability of an external system does not stop the process — we set timeouts, retries, and a queue of deferred tasks.
We record the technical requirements in a document before work begins: which systems are affected, who owns the access, and what happens if each integration fails. This removes the main implementation risk — not the engine itself, but uncoordinated junctions between systems.