Camunda 8 deep dive: BPMN, DMN and FEEL decision design

Use a sandbox request with requestId as a string, amount as a number, currency as a string and riskBand as an agreed enumeration. These are teaching examples, not KaribuTech lending or insurance rules. Keep money precision and currency conversion in a deliberately designed application contract rather than assuming an unqualified numeric amount is sufficient.

Document required fields, who supplies them and which activity may update them. Validate missing, null and incorrectly typed values before evaluating a decision. A string containing 1500 is not a substitute for the numeric value 1500; do not rely on implicit coercion.

Model Start → Validate request → Evaluate routing → Exclusive gateway → Approve automatically or Review request → End. Use a business rule task to call the deployed DMN decision, with a stable decision ID and a binding supported by your installed version. Make the returned routing result an explicit process variable through output mapping.

Keep eligibility or routing rules in the decision model and work sequencing in BPMN. A decision evaluates inputs; it does not independently send a notification, execute a payment or assign a human task. Preserve the evaluated inputs and decision version where needed for an auditable explanation.

For an illustrative table, route a valid low-risk request with amount at or below 1000 to automatic approval and other valid requests to review. Under UNIQUE, make the rules mutually exclusive so that only one row matches; overlapping rows violate that policy. FIRST resolves matches in row order, so reordering rows can change behaviour. COLLECT returns multiple matches, with aggregation only where the selected policy supports it.

Do not select FIRST merely to hide accidental overlaps. Decide what should happen when no rule matches, when inputs are absent and when a new risk band arrives. Model validation or a review result explicitly rather than assuming the table will invent a safe fallback.

In Camunda expression properties, a condition such as = amount <= 1000 and riskBand = "low" illustrates a boolean routing expression. FEEL uses a single equals sign for equality; the initial equals sign marks an expression in the model property. DMN cells have their own unary-test syntax, so do not copy a complete property expression into every cell.

Configure an explicit default sequence flow for the exclusive gateway and ensure ordinary conditions produce the intended boolean results. A default flow handles the absence of a matching route; it is not a replacement for validating malformed data or repairing an evaluation error. Confirm property syntax in the documentation for the selected model execution target.

Use input mappings to pass only the decision inputs and output mappings to preserve a clear result name. Local subprocess variables are not automatically a clean substitute for a documented parent-level contract. In parallel branches, avoid competing writes to the same variable; return branch-specific results and merge them deliberately.

A parallel gateway starts all outgoing paths and joins the expected incoming paths. An exclusive gateway selects one outgoing path and does not synchronise parallel work. Review every split and join together to avoid waiting for a branch that never executes.

Evaluate amounts 999, 1000 and 1001 with low risk, then repeat with a different risk band. Test missing amount, null riskBand, amount as a string and an unexpected currency. The expected outcomes should be written before running the tests, including rejection or review for invalid inputs.

Deploy the BPMN and DMN to a sandbox and follow each resulting instance in Operate. Check the recorded decision output and the selected path, not just that deployment succeeded. Retain the model versions and results; this guide describes an exercise rather than a completed benchmark.