Business rule logic

Write the rule a decision step follows, check it, test it, and hand it over as BPMN and DMN.

A process map that says "the clerk decides" is where automation stalls and audits ask questions. In Handoff Register a decision step can carry a rule table: the inputs it looks at, a condition on each, and where each rule sends the case. The table is checked for overlaps, gaps and a missing default, can be tested with sample values, and goes into the exports as an exclusive gateway with a condition on every flow and as a DMN 1.3 decision table.

Open the specimen's worked rules Download the specimen .dmn

Five steps, one rule table, drawn

Drawn by the register from the BPMNDI coordinates in its own file: the decision step as a business rule task, the gateway after it, the conditions on the flows, the default flow marked, and a named route as its own task.

The specimen's two worked tables

The 32-step specimen, warehouse receiving to dispatch, carries a first-match table on the credit check and a unique table on the freight choice. On the specimen run both can be edited and tested.

Step 12 Check the customer is within their credit limit before releasing the order.

Release the order or hold it for credit. Hit policy: first match. Default route: Route: Finance manager review.

#	Over credit limit `overCreditLimit` yes / no	Customer type `customerType` text	Order value `orderValue` number	Route
1	Over credit limit: yes	any	any	Step 13: If the order is on credit hold, finance releases it or calls
2	Over credit limit: no	Customer type = new	Order value > 10,000	Route: Finance manager review
3	Over credit limit: no	any	any	Step 14: Applies the customer's contract pricing to the order lines

In plain words

The rules are read in order; the first that matches decides.
Rule 1: If Over credit limit: yes, go to Step 13: If the order is on credit hold, finance releases it or calls.
Rule 2: If Over credit limit: no and Customer type = new and Order value > 10,000, go to Route: Finance manager review.
Rule 3: If Over credit limit: no, go to Step 14: Applies the customer's contract pricing to the order lines.
Otherwise, go to Route: Finance manager review.

The conditions on the gateway's flows (FEEL)

Step 13: If the order is on credit hold, finance releases it or calls: overCreditLimit = true
Route: Finance manager review: overCreditLimit = false and customerType = "new" and orderValue > 10000 (also the default)
Step 14: Applies the customer's contract pricing to the order lines: overCreditLimit = false and not(overCreditLimit = false and customerType = "new" and orderValue > 10000)

Clean Checked 5 kinds of case: every case reaches exactly one route (first match), no rule is dead, and the default catches anything new.
Note Rules 2 and 3 overlap when Over credit limit: no, Customer type = new, Order value above 10,000; with first match, rule 2 wins.

Step 26 Decide whether the order goes express or standard from the promised date.

Express or standard freight. Hit policy: unique. Default route: Next step (step 27).

#	Days to promised date `daysToPromisedDate` number	Order weight kg `orderWeightKg` number	Route
1	Days to promised date < 2	any	Next step (step 27)
2	Days to promised date ≥ 2	Order weight kg ≤ 30	Step 28: Sort out the Friday stuff for the big account.
3	Days to promised date ≥ 2	Order weight kg > 30	Route: Pallet freight booking

In plain words

Exactly one rule may match any case.
Rule 1: If Days to promised date < 2, go to Next step (step 27).
Rule 2: If Days to promised date ≥ 2 and Order weight kg ≤ 30, go to Step 28: Sort out the Friday stuff for the big account..
Rule 3: If Days to promised date ≥ 2 and Order weight kg > 30, go to Route: Pallet freight booking.
Otherwise, go to Next step (step 27).

The conditions on the gateway's flows (FEEL)

Next step (step 27): daysToPromisedDate < 2 (also the default)
Step 28: Sort out the Friday stuff for the big account.: daysToPromisedDate >= 2 and orderWeightKg <= 30
Route: Pallet freight booking: daysToPromisedDate >= 2 and orderWeightKg > 30

Clean Checked 7 kinds of case: every case reaches exactly one route, no rule is dead, and the default catches anything new.

specimen-rules.dmn: 2 decision tables, 6 rules, DMN 1.3, 10,419 bytes.
specimen-rules-as-is.bpmn: the process with both business rule tasks and their gateways, 6 routed flows, 114,133 bytes.

What goes where

In the rule table	In the BPMN 2.0 file	In the DMN 1.3 file
The decision step	`bpmn:businessRuleTask` with `implementation` set to DMN, `camunda:decisionRef` and an `hr:decision` extension carrying the table	`decision` with `usingTask` and `usingProcess` pointing back at the .bpmn file
Inputs (number, text, yes / no)	FEEL variable names in the conditions	`input` clauses with `inputExpression` and `typeRef`; `inputData` with information requirements
Each rule	Its condition, in FEEL, on the flow to its route	A `rule` row: one unary test per input, the route as the output entry, your note as the description
Hit policy	Under first match each flow excludes the earlier rules it overlaps, so the gateway takes the same route the table does	`hitPolicy="FIRST"` or `"UNIQUE"`
Default route	The gateway's `default` flow, which carries no condition	`defaultOutputEntry` on the output
A named route or lane	A task named after the route in the matching lane, then on to the next step	An output value
Source, owner, effective date	In the business rule task's documentation	In the decision's description

How it is checked

Every .dmn the tool writes is validated against the OMG DMN 1.3 XML schema (DMN13.xsd with DMNDI13.xsd, DC.xsd and DI.xsd) and opened in the open-source dmn-js viewer with zero import warnings, each decision table showing its rules, inputs and hit policy.
Every .bpmn with rules is validated against the OMG BPMN 2.0 schema and opened in bpmn-js with zero warnings, the business rule tasks, gateways and condition labels drawn.
For every kind of case the table can see, the flow whose FEEL condition holds (or the default) is checked to be the route the table gives, under first match and unique.
The specimen with its rules is exported, imported and read back to the same tables.

Free and paid

Free, no account: the specimen's two worked tables, editable and testable, with both downloads.
Solo: rule tables on your own process, the checks, the test panel, the .bpmn and .dmn files, import of gateway conditions, and the rules saved with the register.
Team: the same for every saved register, with every change to a rule table in the register's change log.

Pricing.

What it does not do

It does not execute the rules or run the process: the files are a model your workflow or rules engine imports. It does not take free FEEL expressions, calculations or dates as conditions, decisions that feed other decisions, or hit policies other than first match and unique.

Questions

What is a rule table in Handoff Register?

A decision table attached to one step of the process: the inputs the decision looks at (a number, a text value or yes / no), a condition on each input for every rule (equal, not, less than, at most, more than, at least, between, one of, or any), the route each rule sends the case to, a hit policy and a default route.

Which hit policies are there?

First match, where the rules are read in order and the first that matches decides, and unique, where exactly one rule may match any case. These are the DMN hit policies FIRST and UNIQUE.

What does the check find?

Field errors (a value that is not a number, a range with its ends reversed, a rule with no route, a route to the step itself), overlapping rules in a unique table, a rule that can never fire under first match, cases no rule covers, and a missing default route, each with an example case in plain words. The check splits the inputs on every value the rules name, so it looks at every kind of case, not a sample.

Where can a rule send the case?

To the next step, to any later or earlier step of the process, to the end, to a lane, or to a route you name. A named route appears in the BPMN diagram as its own task.

What goes into the BPMN file?

The decision step becomes a business rule task linked to its DMN decision, followed by an exclusive gateway. Every outgoing flow carries a FEEL conditionExpression that means exactly what the table means, under first match too, and the default route is the gateway's default flow. The diagram shows the conditions on the flows.

What is in the .dmn file?

A DMN 1.3 definitions file with one decision table per rule table: input clauses with FEEL names and types, the output route with its allowed values and default, one rule per row with FEEL unary tests, input data and information requirements, a diagram (DMNDI), and usingTask links back to the business rule task in the .bpmn file.

Can I import rules from an existing .bpmn file?

Yes, on Solo and Team. Conditions on a deciding gateway's flows (JUEL such as ${amount > 10000}, FEEL, or the usual &&, ||, ==) become a rule table on the step before the gateway, with the default flow as the default route. A condition that cannot be read, such as a method call, is counted and left out, never guessed.