Your process as a BPMN 2.0 model: as-is, the to-be after the hand-overs, and the reason on every task.
Handoff Register reads the steps of a process the way you would write them for a new hire and classifies each one. It then writes the result as a BPMN 2.0 file with its diagram: one lane per owner you named, every step a task in the order you wrote it, keep steps as user tasks and hand-over candidates as service tasks, re-keyed data flagged, and the classification and findings carried inside each task. The file opens in BPMN modelling tools; we test it in the open-source bpmn-js viewer.
Five steps, both views
Drawn by the register from the BPMNDI coordinates in its own file. Left the process as written, right the draft after the hand-overs.
The specimen files
The 32-step specimen, warehouse receiving to dispatch, exported exactly as the tool exports it:
- specimen-as-is.bpmn: 32 tasks, 12 lanes, 6 decisions stated in the paste, 8 re-keying steps flagged, 100,906 bytes.
- specimen-to-be.bpmn: 20 hand-overs moved to the automation lane, 4 reviews added where nothing checked a hand-over, 105,919 bytes.
What is in the file
| In the register | In the BPMN 2.0 file |
|---|---|
| Each step, in the order written | A task, joined by sequence flows; a start event before the first and an end event after the last |
| Keep (a person stays accountable) | bpmn:userTask, drawn green |
| Hand over (a candidate for an automation or AI layer) | bpmn:serviceTask, drawn brick; a marker with no implementation, and the process is isExecutable="false" |
| Unclear (nothing matched, not guessed) | bpmn:task, drawn grey, with the four questions in its documentation |
| Re-keying: a person copying data between systems | rekeyed="true" on the task's classification, drawn with an ochre band |
| The owner named on a line | A lane in the pool; steps with no owner go to a lane that says so; with no owner anywhere, one lane |
| A step that states a condition ("if", "unless") | An exclusive gateway with the condition as its name and on the branch, the step on the branch, a merge after it; never invented where the paste states none |
| "If ..., go back to step 3" | The branch flows back to step 3 |
| Kind, verdict, why, what you lose, first move, systems, findings | The task's documentation in plain words, and the same fields machine-readable in extensionElements as hr:classification |
| Findings and their clauses | Each finding with the ISO 9001 and ISO/IEC 42001 clause codes it points to as evidence; labelled the register's findings, not a statement of conformity |
| Verdict colours | The bpmn.io colour attributes and the OMG non-normative colour attributes on every shape |
| Name, view, export date, exporter and version | On the definitions and in the documentation; the SVG and PNG carry the same footer |
A step with a rule table is written as a business rule task followed by an exclusive gateway, with a FEEL condition on every flow and the decision table in a DMN 1.3 file.
Element ids follow the step's position (Task_s7, Gateway_s3), so the same paste exports the same file and rewording a step changes no id.
As-is and to-be
The as-is is the process as written. The to-be is a draft after the hand-overs, not a redesign: every hand-over step moves to an Automation (handed over) lane as a service task, kept and unclear steps stay in their owner's lane, and a review task is added only where the register found a hand-over that writes to a system of record with no check after it, or that nothing downstream would see. Nothing else is re-sequenced, because the paste does not say how.
Import a .bpmn file
On Solo and Team, pick a .bpmn file or paste its XML into the box. Tasks of every kind (user, service, manual, script, send, receive, business rule, call activity, sub-process) are read in flow order from the start event, across every pool; lane names, nested lanes included, become owners; a named branch out of a deciding gateway becomes an "If" line the register can read. A file the register exported carries each step as written, so exporting and importing it gives back the same register. Short modeller labels ("Check order") classify less well than sentences; a line the register cannot classify comes back unclear with four questions, never a guess.
How it is checked
- Every export path is validated against the OMG BPMN 2.0 XML schema (BPMN20.xsd, Semantic.xsd, BPMNDI.xsd, DC.xsd, DI.xsd): the specimen as-is and to-be, the free 12-step file, a 60-step process, the five paste shapes, a rework loop and a file full of ampersands, quotes and angle brackets.
- The same files are opened in the open-source bpmn-js viewer with zero import warnings, and every task, lane, gateway and flow is counted on the drawing.
- The specimen is exported, imported and classified again, and must give back the same steps and verdicts.
Free and paid
- Free, no account: the as-is diagram and its .bpmn, SVG and PNG for the first 12 steps of your own process; the specimen with both views in full.
- Solo: the whole process, the as-is and the to-be, every download, and .bpmn import.
- Team: the same for every saved register.
What it does not do
It does not simulate, execute or edit a process: the file is a model to open in your own modelling tool. It does not infer parallel paths, events, messages or data objects the paste does not state.
Questions
What does the .bpmn file contain?
A BPMN 2.0 definitions file with one pool, one lane per owner named in the paste, one task per step in the order written, a start and an end event, an exclusive gateway only where a step states a condition, sequence flows, and BPMNDI diagram coordinates for every shape and flow.
Which task types does it use?
userTask for a step a person keeps, serviceTask for a hand-over candidate and task for a step the register could not classify. The serviceTask is a marker for a candidate, with no implementation; the process is marked isExecutable="false".
Is the file valid BPMN 2.0?
Every export path is validated in the product's smoke tests against the OMG BPMN 2.0 XML schema (BPMN20.xsd with Semantic.xsd, BPMNDI.xsd, DC.xsd and DI.xsd) and opened in the open-source bpmn-js viewer with zero import warnings.
What is the to-be view?
A draft after the hand-overs, not a design: every hand-over step moves to an automation lane as a serviceTask, kept and unclear steps stay with their owner, and a review task is added only after a hand-over the register found nothing checks.
Can I import an existing .bpmn file?
Yes, on Solo and Team. The tasks are read in flow order with their lane names as owners, a named branch out of a deciding gateway becomes an "If" line, and the steps are classified as usual. Short modeller labels classify less well than sentences.