Build your first decision

A DMN decision is a spreadsheet-shaped set of rules — a decision table — that a BPMN process can call from a Business Rule task. In this tutorial you’ll build a loan-approval table, exercise all five hit policies on it, and wire the result into a gateway.

Note

Decision Models is Business-tier and not yet available in a released build — see Decision models (DMN) for exactly what that means. This tutorial exercises the engine and editor as implemented; to follow along on a local build you need a Business licence or above (or ORVANTA_DEV_TIER=business for local dev) and ORVANTA_BETA=true to reveal the still-hidden decision_models surface.

Prerequisites: an Orvanta CLI session logged in and bound to a workspace (orvanta workspace) — see CLI overview.

1. Create the decision table

   orvanta dmn new f/demo/loan_approval --summary "Loan approval"

   This writes loan_approval.dmn (an empty decision table) and its loan_approval.dmn_decision.yaml sidecar locally — see orvanta dmn.

2. Open it in the editor

   In your Orvanta dashboard, open f/demo/loan_approval on the decision-table editor. Set the hit policy to UNIQUE, then add three input columns and one output column:

   Column	Label	Expression / name
   Input	Age	age
   Input	Country	country
   Input	Amount	amount
   Output	—	decision

3. Enter the rules

   Add five rules with these cells — non-overlapping by construction, so UNIQUE is satisfied:

   #	Age	Country	Amount	decision
   1	< 18	-	-	"DECLINED"
   2	>= 18	"NL","BE"	< 5000	"APPROVED"
   3	>= 18	"NL","BE"	[5000..20000)	"REVIEW"
   4	>= 18	"NL","BE"	>= 20000	"DECLINED"
   5	>= 18	not("NL","BE")	-	"REVIEW"

   Rule 5’s not("NL","BE") is what keeps it from ever overlapping rules 2–4: those three already claim every NL/BE applicant, so rule 5 only ever matches everyone else. See the cell grammar for what not(...), comma lists, and mixed-bracket ranges like [5000..20000) mean.

4. Test it

   In the test panel, try {"age": 30, "country": "NL", "amount": 10000} — it should match rule 3 and return "REVIEW". Save a draft (Save draft) once you’re happy, or deploy straight away with Deploy. From the command line, the same evaluation:

   orvanta dmn eval f/demo/loan_approval --data '{"age":30,"country":"NL","amount":10000}'

5. See FIRST take the earliest match instead of the most specific one

   Switch the hit policy to FIRST and drop rule 5’s not(...) to a bare - (so it becomes an unconditional default for anyone 18 or over), moving it to the end. Evaluate {"age": 30, "country": "DE", "amount": 25000} — rule 4 (>= 20000, "DECLINED") now wins over the default because FIRST stops at the first matching row in table order, not the most specific one.

6. Trigger a UNIQUE violation on purpose

   Switch back to UNIQUE and duplicate rule 2 with a wider amount condition (< 10000 instead of < 5000), leaving the original rule 2 in place. Evaluate {"age": 30, "country": "NL", "amount": 3000} — both rules now match, and UNIQUE rejects that as a hit-policy violation rather than picking one silently.

7. Switch to COLLECT and see both outputs

   With the same overlapping pair of rules from step 6, switch the hit policy to COLLECT. The same input now evaluates successfully, and decision comes back as a list — ["APPROVED", "REVIEW"] — one entry per matching rule, in table order.

8. Rank the same overlap with PRIORITY

   Switch to PRIORITY and declare output values on the decision column, most important first: "APPROVED","REVIEW","DECLINED". Evaluate the same overlapping input again — this time exactly one result comes back, "APPROVED", because PRIORITY picks whichever matching rule’s output ranks highest in that declared list.

   Delete the duplicate rule and switch the hit policy back to UNIQUE with the original five rules before continuing — that’s the version you’ll deploy and call from BPMN.

9. Create a BPMN process that calls it

   orvanta bpmn new f/demo/loan_process --summary "Loan process"

   Open it on the BPMN canvas. Add a Business Rule Task, give it the id LoanDecision, and on its Behaviour tab pick f/demo/loan_approval from the decision picker — this writes the orvanta:decisionRef extension attribute onto the element. See orvanta:decisionRef.

10. Branch on the result

    Add an Exclusive Gateway after the Business Rule task, with two outgoing flows:

    • A conditioned flow with the JavaScript condition results.LoanDecision.decision === "APPROVED", to an end event.
    • A default flow (toggle it in the flow’s inspector) to a second end event, for every other outcome.

    Gateway conditions are plain JavaScript, not FEEL — see Element reference — so this reads the decision task’s own output the same way any other activity result is addressed: results.<elementId>.

11. Run it

    Use the canvas’s Run button to start an instance without deploying first — fill in {"age": 30, "country": "NL", "amount": 3000} as the start payload. The Business Rule task should evaluate to "APPROVED" and the process should end on the approved branch. Once deployed, every run and its token-level state is visible at /bpmn-runs/f/demo/loan_process (and /bpmn-run/<id> for one specific run) — see BPMN Flow overview.

What next?

• Decision models (DMN): the full hit-policy table, FEEL cell grammar, and engine limits.
• The decision-table editor: every control on the Visual/XML editor and its test panel.
• orvanta dmn: the CLI surface used in this tutorial.
• BPMN Flow overview and Element reference: the rest of what a BPMN process can do.