BPMN Reference
Workflows · BPMN reference
Read a workflow drawing, choose the right branching pattern, and distinguish the BPMN notation from the settings that make it run in NIM.
Business Process Model and Notation (BPMN) is a standard visual language for describing business processes. The Object Management Group (OMG) publishes the BPMN 2.0.2 specification. NIM uses a supported subset of its shapes for workflow definitions.
Use this page to understand the notation. Use the NIM configuration guides for execution behavior: participant binding, App mappings, gateway conditions, and timers are configured in NIM. External BPMN tools may support constructs or expressions that NIM does not. NIM's documented definition import/export uses JSON; the diagrams below are illustrations, not importable workflow files.
Read the basic symbolsDirect link to Read the basic symbols
Follow each arrow in its direction. A token represents progress through the drawing: it waits at a task or event, follows the selected branch, and disappears at an end event. Parallel paths can create more than one token.
| Symbol | Meaning in NIM | Configure or use it |
|---|---|---|
| Thin circle: start event | The single entry point of a definition. | Choose the start App and map its input into the case. |
| Thick circle: end event | The end of one path. A case completes when every token has reached an end event. | End every path, including refusal and reminder paths. |
| Rounded rectangle with person: user task | A person completes a step in a NIM App or, when allowed, from a task list. | Name a participant; configure the App and exchanged variables. |
| Rounded rectangle with gear: service task | The NIM service runs configured actions. | Configure target system functions, script functions, or service resource commands. |
| Rounded rectangle with send marker: send task | Send mail to the task's participant, then continue. | Couple a template to the step's notification event. |
| Double circle with clock: timer event | Wait for a duration or a date. | Configure the timer on the Steps tab. |
| Double circle with envelope: message event | Wait for a message from the named participant. | Use a workflow message action, for example to withdraw a request. |
| Solid arrow: sequence flow | Connect the steps in execution order. | Label gateway branches and set positive/negative meanings where needed. |
See Supported elements for the complete NIM palette and Configure each step for its settings.
Choose a gatewayDirect link to Choose a gateway
| Need | Gateway | What happens |
|---|---|---|
| Choose one path, such as approved or rejected | Exclusive: diamond with × | One outgoing branch runs. In NIM, route by the previous outcome, a case variable, or branch conditions. |
| Start several paths and wait for all of them | Parallel: diamond with + | The split starts every branch; the matching join waits for every branch to arrive. |
| Continue when the first timer or message arrives | Event: diamond with event marker | The first event wins; the other waiting branches are dropped. Each branch must begin with a timer or message event. |
| Stop outstanding approvals after a refusal | Cancelling join: diamond with asterisk | NIM's supported complex-gateway pattern continues negatively after the first refusal and withdraws the other open steps. |
An exclusive join does not wait for parallel branches. Use a parallel join when all branches must finish, or NIM's cancelling join when a negative decision must stop the remaining approvals. Validate and simulate both successful and unsuccessful paths before publishing.
Pattern: approve before provisioningDirect link to Pattern: approve before provisioning
Use a user task for the decision and an exclusive gateway for the outcome. Only the approved branch reaches the service task that changes access.
- Name the user task's participant, such as
Manager, in the definition. - Label the outgoing branches
ApprovedandRejected; set their meanings to positive and negative for fixed approve/reject buttons. - Bind
Managerto the appropriate NIM users or groups in the configuration. - Configure the step App and the service task's provisioning action.
- Simulate both decisions, then test with safe target data after publishing.
Check the distinction: An approved decision permits the next step; it does not prove the target change succeeded. Inspect the service task and case history to verify the result.
Pattern: complete parallel reviewsDirect link to Pattern: complete parallel reviews
Use a parallel split when two independent reviews can happen at the same time. Use a parallel join when the next step must wait for both reviews to finish.
This drawing illustrates completion of both reviews, not an approval policy. A parallel join does not examine whether a reviewer approved or rejected. For parallel approvals where one refusal stops the request, add the outcome gateways and cancelling join shown in the designer guide.
Pattern: remind without withdrawing the taskDirect link to Pattern: remind without withdrawing the task
A non-interrupting boundary timer sits on a user task's border. When it fires, the reminder path runs while the original task remains available.
- Use a non-interrupting timer for a reminder. Its path must have its own end event.
- Use an interrupting timer for a deadline that withdraws the task and continues along another path, such as escalation.
- A timer is checked once per minute in NIM. This example is a single reminder, not a repeating timer.
- Configure the send task's participant and notification template. Drawing a send task alone does not send mail.
See Boundary events and Timer event for the supported restrictions and timer settings.
Model a process that can finishDirect link to Model a process that can finish
Make responsibility explicit
Name participants on user tasks, send tasks, and message events. Bind people in the configuration, rather than treating a role name as an account.
Cover every outcome
Model approval, refusal, withdrawal, and deadlines where the process needs them. Give every path an end event.
Validate and simulate
Check drawing validity and soundness, then fire each branch in the simulator. Correct deadlocks and stranded tokens before publishing.
NIM does not support every BPMN construct. Check What is not supported before adopting a pattern from another tool. For exact error messages and fixes, use the Workflow validation reference.
External BPMN referencesDirect link to External BPMN references
These resources explain the standard and its notation. NIM's documentation remains the reference for NIM behavior.
| Resource | Use it for |
|---|---|
| OMG BPMN 2.0.2 specification overview | The authoritative specification, schemas, and links to official example documents. |
| OMG BPMN 2.0.2 specification PDF | Detailed definitions and standard execution semantics. |
| Camunda BPMN primer | An introduction to sequence flows, tasks, events, and tokens. |
| Camunda BPMN symbol reference | Visual examples of BPMN symbols and process patterns. |
Related guidesDirect link to Related guides
- Workflow definitions — draw, validate, and simulate a process in NIM.
- Workflow configurations — connect Apps, data, actions, and routing.
- Workflows and Approvals — plan the identity process before building it.