Use decision tables to make changing business rules testable and separate from process flow. DMN training is not a stand-alone Camunda credential.
Use BPMN to coordinate activities and DMN to determine an outcome from inputs. This separation helps analysts review rules without scanning a web of conditional process branches.
Try it: Extract a loan-risk rule from a process sketch; name the input data and the output the process needs.Write rules that cover expected input combinations and make overlap or missing cases visible. Give inputs and outcomes names a reviewer can understand, then test boundary values.
Try it: Make a three-level risk table using amount and customer status. Test a threshold value, a missing value, and a combination that matches no rule.A decision is useful only when the BPMN model handles its result. Define the variable contract and expected route for each outcome, including an unexpected or invalid result.
Try it: Route approved, manual-review, and declined outcomes to separate steps and explain what an operator sees if the decision evaluation fails.A decision table needs an explicit answer to what happens when several rules match. A unique-hit design assumes no overlap; other hit policies allow different result behavior. The safest policy depends on the business rule, not on what happens to be selected in a modeler. For an approval threshold, accidental overlap might approve a case through the wrong row, while a missing rule may leave the process without a usable result. Before adding more rows, define whether multiple matches are valid, whether rule order matters, and how a no-match result should be handled by the calling process.
Try it: Construct test inputs that match exactly one row, two rows, and no row. Record the expected result for your chosen hit policy and the BPMN route after each result.DMN inputs may be numbers, strings, dates, or other supported values. A value that looks numeric but arrives as text can change rule evaluation, and null or missing data deserves an explicit decision. Camunda uses FEEL expressions in decision models, so read and test the actual expression rather than inferring behavior from a column heading. Document which service or user task supplies each input, its type, allowed range, and whether it can be absent. The process should receive a stable outcome name that downstream routes can interpret without relying on a display label.
Try it: For a risk table, test amount at 999, 1000, and 1001, plus missing customer status and a string-valued amount. Explain which cases require validation before evaluation.A decision table makes policy changes visible, but it does not decide who may approve those changes or how a new version is tested. Keep example cases beside each rule change, including boundary and conflict cases, and review the intended output with the policy owner. In a practice project, retain the old expected outputs, run the same cases against the changed table, and investigate every difference. This separates an intentional policy update from an accidental regression. Camunda's DMN documentation is the technical source for modeling behavior; organizational approval rules remain the team's responsibility.
Try it: Add one new rule to a sample approval table. Produce a short change note listing the business reason, affected examples, reviewer, and tests that would block an unsafe release.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.