BPMN

In BPMN 2.0 a start event (thin circle) only catches the trigger that creates a process instance, an end event (thick circle) only throws a result as it consumes a token, and an intermediate event (double circle) may catch or throw.

In BPMN 2.0 a sequence flow (solid line, solid arrowhead) orders flow nodes inside one process and carries the token; a message flow (dashed, open circle to open arrowhead) passes a message between pools; an association (dotted) only attaches information.

In BPMN 2.0 an exclusive gateway takes exactly one branch and merges without waiting; an inclusive gateway takes every branch whose condition is true and joins those still expected; a parallel gateway takes all branches and waits for all.

In BPMN 2.0 a pool is the graphical form of a participant, such as the employer or the candidate, and contains at most one process; a lane is a sub-partition inside that process, such as Recruiting or Hiring manager.

In BPMN 2.0 an embedded sub-process is part of its parent and shares its data; a call activity (thick border) reuses a separately defined process or global task; an event sub-process (dotted border) has no sequence flow and starts on its own trigger.

In BPMN 2.0 an interrupting boundary event (solid border, cancelActivity=true) cancels the activity and sends the token down its exception flow; a non-interrupting one (dashed border, cancelActivity=false) leaves the activity running and starts an extra parallel token.

A BPMN 2.0 diagram usually lacks what execution needs: isExecutable set to true, formal condition expressions instead of prose, implementation details on service and user tasks, typed data with inputs, outputs and data associations, and full definitions for messages and timers.

In BPMN 2.0 a sequence flow never crosses a pool boundary: each pool holds a separate participant's process. The order is a message flow, consumed by the supplier's message start event, receive task or message catch event.

In BPMN 2.0 an instance waits at user tasks until the assignee finishes, at receive tasks and catching message events until the message arrives, and at timers until they fire. It completes when no token remains and no activity is active.

In BPMN 2.0 a standard loop repeats one activity while a condition holds; a multi-instance activity creates a count fixed up front, run in sequence or in parallel. Its completionCondition, checked as each instance completes, cancels the rest when true.

In BPMN 2.0 an error is critical: its end event terminates the sub-process's active paths and an always-interrupting boundary event catches it. An escalation is non-critical: work continues where it was thrown, and the catching boundary event may be non-interrupting.

In BPMN 2.0 a top-level start event catches none, message, timer, conditional, signal, multiple or parallel multiple; an end event throws none, message, error, escalation, cancel, compensation, signal, terminate or multiple; a boundary event catches anything except none and link.

In BPMN 2.0 a data object is visible data living as long as its process or sub-process instance; a property is hidden data on a process, activity or event, living as long as that element; a data store persists beyond the process.

In BPMN 2.0 the process XML holds the model's semantics: elements, flows, data and attributes. The BPMN DI section holds only layout, shapes and edges on a plane, each pointing at a model element. Rendering needs both; execution needs only the model.

In BPMN 2.0 the order is a data object wired by data associations: output from the creating task, input to the checking task. Sequence flow cannot touch data objects, and no token flows along data associations.

In BPMN 2.0 no sequence flow may enter a start event or a boundary event, or leave an end event; gateways take no message flows; start events never send and end events never receive message flows.

In BPMN 2.0 an event-based gateway is followed by catching events or receive tasks, here a documents message and a 14-day timer. The token waits at the gateway; the first event to occur takes its branch and the other is withdrawn.

In BPMN 2.0 several flows entering a task directly form uncontrolled flow: each arriving token starts the task on its own, like an exclusive merge. Draw an explicit parallel or inclusive gateway whenever arrivals must be synchronised.

In BPMN 2.0 a black-box pool references no process and message flows attach to its boundary; use it when the agency's internals are unknown or not yours to model. Use a white-box pool when its activities matter.

In BPMN 2.0 a lane is only a partition of one process: it has no process of its own and is not a party to the collaboration. Naming it after the agency still makes the agency's work part of the employer's process.

In BPMN 2.0 compensation undoes activities that already completed. A handler, either a compensation activity (rewind marker) associated with the activity or a compensation event sub-process, runs only when a compensation event is thrown, in reverse order of the original flow.

In BPMN 2.0 a non-interrupting boundary event adds a second token while the task keeps waiting. Merged into the main flow, that token ships the order once after the reminder and again after payment. End the reminder branch with its own end event.

In BPMN 2.0 an undeclared expressionLanguage defaults to XPath, so FEEL conditions are declared as XPath and cannot be evaluated as intended. Declare the DMN FEEL URI on definitions or each formalExpression, and bind the business-rule task's implementation to the decision.

In BPMN 2.0 every unconditional flow leaving a task gets a token on completion, so 'Send order' always runs alongside approval. Marking it the default flow (slash marker) makes it fire only when no condition holds.

In BPMN 2.0 the exclusive split puts a token on only one branch, but a parallel join waits for a token on every incoming flow. The missing token never comes, so the instance deadlocks. Alternatives must merge with an exclusive gateway.

In BPMN 2.0 one pool is one process with one controller, so this model claims the employer sequences the candidate's and agency's actions. Restructure as a collaboration: employer pool with internal lanes, separate participant pools, message flows.

In BPMN 2.0 a collaboration shows participants as pools exchanging message flows; a choreography models the ordered message exchanges between them with no central controller; a conversation diagram groups related message flows into hexagons for a bird's-eye view.

In BPMN 2.0 a transaction sub-process (double border) is controlled by a transaction protocol. It ends in success, cancel (rollback plus compensation of completed work, then a cancel boundary event) or hazard (interrupted without compensation, then an error boundary event).

In BPMN 2.0 a converging inclusive gateway waits for any token that can still reach its empty inputs. A parallel join checks only its own inputs; the inclusive join must inspect paths across the whole model, so it is non-local and hard to verify.