BPMN Modeler
The BPMN modeler is a web-based diagram editor for authoring, validating, deploying, and test-running BPMN 2.0 processes — all in one place.
Layout
The modeler is a three-pane layout:
| Pane | Contents |
|---|---|
| Left — palette | Categorised list of elements, search, advanced-mode toggle |
| Center — canvas | Diagram area with toolbar, view controls, selection toolbar |
| Right — properties panel | Properties for the selected element |
A header bar above the canvas holds the diagram name, the definitions ID, deployment status, and the Save, Deploy, and Run actions.
Palette
The palette is grouped into Events, Activities, Gateways, and Structural. Each entry can be dragged onto the canvas to create that element.
Search
Type into the search field to filter the palette across categories.
Advanced mode
The palette is split into a basic set (the elements you'll use most) and an extended set (everything else). The extended set is hidden until you flip the Advanced switch.
What appears in basic mode:
| Category | Basic |
|---|---|
| Events | Start event, End event |
| Activities | Generic task, Service task, User task |
| Gateways | Exclusive, Parallel |
| Structural | (none — switch to advanced for sub-processes, call activity, participant) |
Advanced mode adds intermediate/boundary events, the remaining task types (manual, send, receive, script, business-rule), inclusive and event-based gateways, and structural elements (sub-process, ad-hoc sub-process, call activity, participant).
Drag-and-drop
Drag a palette item onto the canvas to drop a new node at the cursor position. Dropping on top of a sub-process or pool nests the new node inside that container.
Pools and lanes
Dropping a Participant entry creates a pool. The first time you drop one onto a plain-process diagram, the existing nodes are auto-wrapped into the new pool. Lanes are added per-pool from the pool's own toolbar — there's no separate lane entry in the palette.
Canvas
Selection and the context pad
Selecting a node reveals a context pad — a hover toolbar with the most common follow-up actions:
| Action | Effect |
|---|---|
| Append task | Create a new service task connected from this node |
| Append gateway | Create a new exclusive gateway connected from this node |
| Append end event | Create a new end event connected from this node |
| Expand / collapse | (sub-process only) Toggle the inline view of the sub-process contents |
| Delete | Remove the node and its incident edges |
Morph menu
A node's type can be changed in place via the morph action on the selection toolbar. The available targets depend on what the selection is:
| If you have… | You can morph to… |
|---|---|
| Any task | Any of the eight task types (generic / service / user / manual / send / receive / script / business-rule) |
| Start event | None / Message / Timer / Signal. Inside an event sub-process: also Error, Escalation, Conditional |
| End event | None / Message / Error / Escalation / Terminate / Compensation |
| Intermediate event | Any catch type (Message / Timer / Signal / Link) or any throw type (None / Message / Escalation / Compensation / Signal / Link) |
| Boundary event | Interrupting (Message / Timer / Error / Escalation / Signal / Conditional), Non-interrupting (Message / Timer / Escalation / Signal / Conditional), or Compensation |
| Gateway | Exclusive / Parallel / Inclusive / Event-based |
Morphing cleans up stale configuration: switching away from a worker-backed task drops its task-definition and headers; switching a start or end event re-shapes the I/O mapping (start events only produce data; end events only consume it); switching to a gateway type that doesn't support a default flow clears the default-flow marker.
Some morph targets are hidden when they would produce an invalid graph — for example, error/escalation/conditional start events are only offered when the start event is inside an event sub-process.
Connecting nodes
Drag from a node's edge handle to another node to create a sequence flow. Cross-pool connections are message flows (rendered with a different style); same-scope connections are sequence flows.
A connection is rejected when:
- The source and target are the same node.
- The two nodes belong to different scopes (for example, a node inside a sub-process can't connect directly to a node in the parent process — use the sub-process's own boundary).
- A boundary event would connect outside its host activity's scope.
Sub-processes
Sub-processes can be expanded or collapsed via their context pad. When expanded, their internal flow nodes are visible and editable inline. When collapsed, the sub-process is shown as a single node and its contents are hidden until you re-expand or drill in.
Canvas toolbar
The canvas has a toolbar with:
| Action | Effect |
|---|---|
| Auto-layout | Re-arranges nodes into a tidy left-to-right flow |
| Undo / Redo | Per-edit history within the current modeling session |
| Search (spotlight) | Jump to any node by ID or name |
| View XML | Open a modal showing the BPMN 2.0 XML the canvas currently produces, with copy-to-clipboard |
| Import XML | Replace the current diagram with parsed BPMN XML |
| Download XML | Save the current XML to a file |
| View settings | Pick the edge style and canvas background |
View settings
The view-settings menu controls cosmetic canvas options that aren't saved into the diagram:
| Edge style | Notes |
|---|---|
| Bezier | Smooth curves |
| Straight | Direct lines |
| Step | Right-angled, with hard corners |
| Smooth step (default) | Right-angled, with rounded corners |
| Background | Notes |
|---|---|
| Dots (default) | Dot grid |
| Lines | Line grid |
| Cross | Crosshair grid |
These preferences are per-user, not per-diagram.
Properties panel
Selecting an element shows its properties on the right. The fields available depend on the element type:
| Element | Properties exposed |
|---|---|
| All flow nodes | ID, name, lane assignment (when in a pool with lanes) |
| Service / send / manual / generic task | Task definition (worker type, retries), task headers, I/O mapping |
| User task | Assignment (assignee, candidate users, candidate groups), form (form key, form ID), I/O mapping, headers |
| Script task | Script body, script format (FEEL), I/O mapping, headers |
| Business-rule task | Called decision (decision ID, result variable, binding type, version tag), I/O mapping, headers |
| Receive task | Referenced message, I/O mapping, headers |
| Call activity | Called process ID, propagate-all-variables flag, I/O mapping, multi-instance characteristics |
| Sub-process / event sub-process | I/O mapping, multi-instance characteristics, triggeredByEvent flag (event sub-process) |
| Ad-hoc sub-process | Active-elements collection (FEEL), completion condition (FEEL), I/O mapping |
| Events (all positions) | Event definition selector + the references it needs (messageRef, signalRef, etc.), interrupting flag (boundary), timer expression, condition expression |
| Sequence flow | Condition expression, default-flow marker (when leaving an exclusive or inclusive gateway) |
| Exclusive / inclusive gateway | Default outgoing flow |
Expression fields (FEEL) use a CodeMirror-based editor with autocomplete, hover, and inline diagnostics powered by the FEEL language server.
For the full set of XML attributes and validation rules each element accepts, see the Elements reference.
Saving and versioning
Saving runs validation first, then writes the diagram. The exact behavior depends on what the diagram is:
| State | Save behavior |
|---|---|
| New diagram (never saved) | Creates a new resource |
| Saved draft, not yet deployed | Asks whether to overwrite the current draft or save as a new version |
| Saved and deployed | Always saves as a new version (the deployed version is preserved) |
The diagram name and the definitions ID can be edited in the header. Both are saved with the diagram.
A "browser memory" notice appears when you have unsaved nodes on the canvas — until you save, the diagram lives only in the browser and would be lost if you navigate away.
Validation
Validation runs every time you save. It produces two kinds of issues:
| Severity | Effect |
|---|---|
| Error | Save is blocked. Errors are listed in a banner at the top of the canvas, each pointing at the element ID where the issue lives |
| Warning | Save proceeds. Warnings show as a transient notification |
The same checks documented on each element page (default-flow rules, link-event pairing, boundary-event placement, multi-instance / standard-loop mutual exclusion, reference integrity, and so on) run here.
Deploying
Saving and deploying are separate steps:
- Save writes the draft and arms validation. Drafts can be edited freely.
- Deploy activates a saved draft as a runnable version. Once a version is deployed it can be started, called from other processes, and reached by typed start events (message / signal / timer registrations).
The Deploy button only appears on saved drafts that aren't already deployed. After deploy, the badge in the header switches to Deployed.
Re-deploying a new version of the same process automatically retires the previous version's typed start-event registrations and arms the new ones.
Testing from the modeler
Once a diagram has been saved (deployed or not), the Run button starts a test instance directly from the modeler.
- Click Run to open the Initial variables dialog.
- Enter the starting variables as JSON. Leave it as
{}if the process doesn't need any. - Click Start.
While a test instance is active:
- The canvas becomes read-only and active elements are highlighted as the instance progresses.
- A Run panel opens to the right of the canvas with the live instance state, incidents, and operational controls (resolve incidents, send a message, send a signal — see Operating live instances).
- A "New Run" button replaces "Run" — clicking it starts a fresh test instance.
- For ad-hoc sub-processes, the run panel offers a control to activate specific child activities by ID.
Clicking a call activity while a test instance is running navigates into the live child instance, with a breadcrumb back to the parent.
Working with multiple processes
A diagram that uses call activities invokes another process. The modeler keeps a breadcrumb of the chain you've drilled through.
| Action | Result |
|---|---|
| Click a call activity in static editing mode | Opens the called process in the modeler with a breadcrumb back to the parent |
| Click an ancestor in the breadcrumb | Navigates back to that level and truncates the chain |
| Click "back" | Returns to the immediate parent |
The breadcrumb encodes the chain in the URL, so links to a call-activity-deep view are shareable.
Read-only mode
The modeler is read-only when:
- You don't have edit permission on the project (Viewer or Executor role).
- A test instance is running (the canvas locks until the run ends).
In read-only mode the palette is hidden, the properties panel still shows the selected element's configuration, and the View XML / Download XML actions remain available.