Learn to turn a stakeholder's process narrative into a readable, executable BPMN model with explicit events, ownership, and failure paths.
A strong model begins with a trigger and a meaningful end state. Use tasks for work, events for things that happen, and gateways for routing decisions. Avoid adding notation that obscures who does what next.
Try it: Write a five-step customer-onboarding narrative, then draw its start, normal completion, and two alternate endings.External responses, human approvals, and timeouts create waits. Model these deliberately so the process does not silently stall or treat a technical outage as a business refusal.
Try it: Add an approval timeout and an API failure to the onboarding model; explain which path should notify the candidate and which should alert an operator.Camunda documents that BPMN diagrams must target the intended engine. A Camunda 7 diagram cannot simply be run as-is on Camunda 8; review supported elements and execution properties before deploying.
Try it: Annotate a diagram with its task types, worker responsibilities, and the point where each process variable becomes available.An exclusive gateway takes one outgoing route according to conditions; a parallel gateway starts concurrent routes and later needs a suitable join. Confusing them can either run work that should never occur or leave an instance waiting for a branch that was never started. When a claim can be approved or rejected, model an exclusive choice with a clear default or complete conditions. When identity and address checks can proceed independently, model parallel work only if their combined result is required. Review the join with the same example data used at the split, not merely with the happy-path diagram.
Try it: Take an order with two independent checks and one approval decision. Mark which gateway starts concurrent work, which selects one outcome, and what must arrive before the order advances.A message represents an external fact such as payment received; a timer represents elapsed time or a deadline. If the process waits for payment, model the correlation information needed to reach the correct instance, then decide what happens when no payment arrives by the deadline. A timer must not pretend that payment failed merely because a notification was delayed: write the business rule explicitly. For every waiting event, identify who publishes it, what key identifies the instance, whether duplicates can occur, and what the process should do if the event arrives after the timeout route has already won.
Try it: Draw the payment-wait portion of a booking flow with a correlated message and expiry timer. Walk through payment before expiry, no payment, and a late duplicate callback.A business reviewer should be able to describe the outcome and owner of each path. A developer should be able to identify executable task types, variables, failure handling, and integration boundaries. Keep the primary diagram readable and put detailed worker contracts in supporting notes instead of turning every sequence-flow label into a specification. Before deployment, use Camunda's current BPMN coverage and modeling documentation to check that each chosen element and property is supported by the target Camunda 8 engine version.
Try it: Have a stakeholder explain your onboarding diagram without technical hints, then have a developer list unresolved runtime details. Fix both kinds of ambiguity before treating the diagram as ready.This topic is an independent ITCertPath learning guide, not a separately named Camunda credential. Check current product behavior in the official documentation.
Read the official Camunda documentation ↗Tell us your goal, country and preferred schedule. Ask for the written syllabus, trainer, delivery format, fee and cancellation terms before enrolling.