The path
Capture in patchley, open in Camunda Modeler
patchley does not integrate with Camunda and does not need to. The agreed diagram leaves patchley as a BPMN 2.0 XML file, and your team opens that file in Camunda Modeler. patchley sits upstream, where the process is captured from the people who run it and agreed before anything is built.
Walkthrough
Seven steps from the workshop to the Modeler
The first three steps happen in patchley and with the people who run the process. The rest is your team's work in Camunda Modeler; it is engineering, and the agreed diagram is its specification.
Agree the process in patchley
Capture the As-Is from the workshop, the meeting or the document; mark the control steps; let the process owner sign off the version that will be built. Every version stays, so the signed-off one can always be found again.
Export BPMN 2.0 XML
The export is a standard BPMN 2.0 XML file: the process with its lanes, tasks, gateways, events and sequence flows, the names, and the diagram layout.
Open the file in Camunda Modeler
Camunda Modeler opens BPMN 2.0 XML. The agreed lanes, tasks and gateway questions are in the file.
Add the technical attributes
Process id, versioning conventions, which lanes map to which user groups: the attributes an engine needs and a business diagram does not carry. This is done in the Modeler by your team.
Decide the task types
Which tasks become user tasks for people, which become service tasks calling a system, which stay manual. The systems named on the patchley tasks tell you where to look; the connectors are your team's work.
Add forms and conditions
Forms for the user tasks, expressions for the gateway conditions, timers for the deadlines. The gateway questions and the labelled answers from the agreed diagram are the starting point.
Keep the agreed diagram as the reference
When the technical model changes the process, bring the change back to the people who agreed it. The business version in patchley stays the version they recognise.
patchley and Camunda do not talk to each other. A BPMN 2.0 XML file leaves one and opens in the other, which is what the standard is for. Nothing is synchronised, nothing is pushed, nothing depends on either side's release cycle.
What travels, what is added
In the file from patchley, and your team's work in Camunda
A business diagram and an executable model share the notation but not the purpose. The table separates what the agreed diagram brings from what engineering adds.
| In the BPMN 2.0 XML from patchley | Added by your team in Camunda Modeler | |
|---|---|---|
| Roles | Pool and lanes named after the roles that do the work. | Assignment of lanes and user tasks to groups and users. |
| Tasks | Tasks named verb plus object, with the systems and documents they use. | Task types (user, service, manual), connectors, input and output mappings. |
| Decisions | Gateways named as questions, with labelled outgoing flows. | Condition expressions on each outgoing flow. |
| Events | Start and end events named after trigger and result. | Message and timer definitions, error handling. |
| Controls | Control steps as marked in the agreed diagram. | Approval forms and the rule that the step cannot be skipped. |
| Layout | Diagram interchange: positions and sizes. | Rearranging as the technical model grows. |
Before you build
Why the agreed version is worth the detour
An executable model inherits every gap in the business process it is built on. Three things are cheaper to settle in a workshop than in a sprint.
Decisions with their conditions
"Amount above limit?" is easy to ask in a room and expensive to guess in code. The agreed diagram carries the questions and the answers.
Controls that must not disappear
Four-eyes approvals and compliance checks are marked as control steps, so they are visible when task types are decided.
Exceptions the team knows about
Missing documents, rejected invoices, withdrawn applications: the people who run the process name them in minutes; the model needs a path for each.