A practical route from an executable BPMN model to workers, decisions, tests, and incident handling. This is a training topic, not a separate Camunda certification.
Begin with one business outcome and model its trigger, work, waiting points, and exception paths. A diagram is only useful when a reviewer can predict what the running process will do after each event.
Try it: Model an order that waits for payment confirmation; add a rejected-payment route and explain how the process resumes.A Camunda 8 service task can call a job worker or connector. Define the input, output, timeout, and retry behavior before connecting to an external API; a technical error is not the same as a business rejection.
Try it: Mock a stock-service timeout and an out-of-stock response. Explain which one should be retried and which should route to a business outcome.Prepare tests for the successful journey, decision boundaries, integration failures, and repeated messages. The goal is to know not only whether a process finishes but how an operator can diagnose a stuck instance.
Try it: Create a four-case test matrix and record the expected process state after each case.In Camunda 8, reaching a service task creates a job with a task type. A worker subscribed to that type activates the job, performs application work, and reports completion or failure. That separation is useful because the process can wait while the application scales or restarts independently. It also means the BPMN label alone does not execute code. Design the variables the worker needs, the variables it returns, its timeout, and the owner of its logs. A failed technical call should leave enough information to diagnose the instance without putting credentials or unnecessary personal data into process variables.
Try it: For a Reserve Stock task, write the task type, three required input fields, success output, technical-failure response, and the system that owns each field.A stock service saying 'item unavailable' is a valid business answer; a timeout or connection refusal is a technical failure. The first should normally produce an explicit business route, while the second needs a deliberate retry or incident strategy. Retrying a payment or reservation can repeat a side effect, so include a stable business identifier and an idempotent downstream operation where possible. Camunda's job-worker and incident documentation explains that exhausted retries leave a process instance stuck until the underlying problem is corrected. Training should include what an operator will actually see and who can restore progress.
Try it: Run three versions of one order: reserved, out of stock, and service unavailable. For each, record the BPMN path, worker response, expected retry behavior, and operator action.A useful practice project includes the BPMN diagram, a short decision table, a worker or connector contract, tests, and a one-page operations note. Show one ordinary instance and one failure instance end to end. This evidence is more informative than memorizing element names because it reveals whether a model can be deployed and supported. Use Camunda's current training and Academy material to check what a particular course teaches; this independent learning route is not an official course or a promise that its exercises match a certification exam.
Try it: Ask another learner to explain how your order process resumes after a payment message and how an operator would recover an exhausted worker job; revise any ambiguous step.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.