DMN Decisions

Access level required

Admin or Super Admin. The whole screen — listing, deploying, changing, testing and deleting — is restricted to that role; anyone without it is sent back to the Dashboard.

Evaluating a table remains open to Manager and User through the API (POST /api/a/decisions/{key}/evaluate), which is how processes consult it on behalf of whoever is running the task. What is restricted is the screen.

The Decisions module lists and manages the decision tables (DMN) deployed in your tenant. They hold the business rules a process consults to pick a path or work out a value.

The screen sits under Modeling → Decision Tables, next to Process Catalog.

What is a decision table?

A decision table has one row per rule. The columns on the left are the inputs — what the process supplies — and the ones on the right are the outputs — what the table gives back.

Example — who approves a purchase:

Amount	Category	→ Approver
≤ 1,000	Any	Direct manager
≤ 10,000	Any	Finance director
> 10,000	Any	Purchasing committee

How many rows answer, and what happens when more than one matches, is set by the hit policy declared in the table itself. Under FIRST, the first matching row wins, top to bottom — that is the behaviour of the example above. Under UNIQUE, which is what applies when the table declares nothing, exactly one row is expected to match. Other policies return more than one result. Each table's hit policy is shown under Details, and that is why row order matters in some tables and not in others.

Viewing the deployed tables

1. Open Modeling → Decision Tables
2. The list shows the name, the key and the version of every table in the tenant
3. Click Details to open the table below the list, read-only: the hit policy, the input columns, the output columns, one row per rule, and the Note column with each rule's annotation

Details is how you inspect a table with no risk of changing it. Close collapses the panel.

Deploying a new table

Tables are deployed from the global DMN templates registered by the Super Admin.

1. Open Modeling → Decision Tables
2. Click Deploy Decision
3. In the Deploy Decision Table window, pick the Global template
4. Click Deploy

The table is deployed with the template's rules and takes effect in the tenant right away. There is no modeler on this path: to adjust the rules afterwards, use XML, described below. If the template list comes up empty, the window says so — the Super Admin has to register the template first.

Sending a .dmn file directly

The platform accepts deploying a .dmn file without a template, but this screen offers no button for it: the path is the API (POST /api/a/decisions, with the file in the file field). See API Reference.

Changing a table's rules

The change takes effect immediately

A changed table changes the behaviour of the next evaluations, including instances already running that have not yet reached the decision point. Change carefully, and use Test before you call the work done.

On the table's row, click XML. The Edit XML window opens with the table's contents as text; change it and click Redeploy to publish a new version. The version shown in the list goes up.

The visual table editor — the one where you click a cell to edit it, and add and remove rows — is not here: it is the modeler for the DMN templates, and only the Super Admin reaches it, under Global (Super Admin) → DMN Templates or Process Catalog → New Definition → DMN Template. A change that should apply to every tenant belongs to the template; a change for this tenant alone is made here, in the XML.

Delete removes the deployed table from the tenant. The global template is untouched.

Testing before it counts

The Test button evaluates the table with no process involved:

1. Click Test on the table's row
2. Write the input variables (JSON) — for example {"amount": 5000, "category": "IT"}
3. Click Evaluate

The result appears in the same window, with the outputs the table gave back. Malformed JSON is refused with a notice, before any call is made.

This is the recommended step after every Redeploy: a rule written with the wrong operator does not fail, it returns something else — and without this test the difference would only show up on the next instance.

Condition types

Type	Example
Equals	"approved"
Numeric comparison	< 1000, >= 5000
Range	[100..500] (inclusive)
List	"SP","RJ","MG"
Any	(empty cell — always true)

Impact on running instances

Changes to decision tables take effect immediately for new evaluations. Instances that have already passed the decision point are not re-evaluated: the result they recorded still stands.