> ## Documentation Index
> Fetch the complete documentation index at: https://aletyx.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Executable Rules Models: DMN in Aletyx Playground
> A 30-minute hands-on walkthrough of building and testing DMN decision models in the browser-based Aletyx Playground.
export const AnnotatedImage = ({src, alt, markers = []}) =>
{markers.map((m, i) =>
{i + 1}
)}
;
Aletyx Playground is a lightweight, browser-based tool for creating, editing, and
testing business processes and decision models. In this guide, you'll explore the
core features of Aletyx Playground and get hands-on experience with both DMN
decision models and BPMN process models.
This guide uses the Aletyx Enterprise Build of Kogito and Drools 10.1.0-aletyx.
Plan for about **30 minutes**.
## Accessing Aletyx Playground
Aletyx Playground is available both as a container that can easily be deployed into
any container orchestration platform and as a local installation option.
Navigate to [playground.aletyx.ai](https://playground.aletyx.ai). No
installation required — just start playing immediately!
As long as you have set up your local environment to meet the Local
Environment Requirements, you can run one of these commands to get started
with everything deployed locally:
```bash macOS theme={null}
curl -sL https://raw.githubusercontent.com/aletyx-labs/kie-10.0.0-sandbox/refs/heads/main/docker-compose.yaml | docker compose -f - up
```
```bash Linux theme={null}
curl -sL https://raw.githubusercontent.com/aletyx-labs/kie-10.0.0-sandbox/refs/heads/main/docker-compose.yaml | docker-compose -f - up
```
```bash Windows theme={null}
curl -sL https://raw.githubusercontent.com/aletyx-labs/kie-10.0.0-sandbox/refs/heads/main/docker-compose.yaml | docker-compose -f - up
```
Then access Aletyx Playground at [http://localhost:9090](http://localhost:9090).
## The Aletyx Playground Interface
When you navigate to Aletyx Playground, you'll see a welcome screen with several
key areas:
The top tiles allow you to create new projects or import existing ones.
Import existing projects or DMN/BPMN files either from various Git providers or
through direct file uploads.
The lower section displays your locally imported projects and models.
The top bar provides access to:
* **Dev Deployments**: Test deployments to connected Kubernetes or OpenShift clusters
* **Extended Services**: Connection to the DMN execution service for testing
* **Settings** (⚙️): Configure your Playground instance, including DMN version settings
* **Profile** (👤): Configure connections to Git providers and Kubernetes environments
Projects in Aletyx Playground are stored in your browser's local storage by
default. For persistent storage and collaboration, connect to a Git provider
under Profile settings. Playground is not designed to be long-term storage of
your BPMN/DMN models and should be regularly synchronized with your Git provider!
## Exploring Decisions with DMN
Let's begin by exploring a sample Decision Model and Notation (DMN) model.
From the welcome screen, click **Try Sample** under the Decision section.
This opens a sample "Loan Pre-qualification" DMN model (DMN 1.5 Specification).
Hover over each numbered marker on the screenshot to see what that part does,
or expand the list below.
1. **Decision Editor** — The currently active section of the editor, showing the DMN model or your current selection.
2. **Decision Connectors** — From a decision, drag the connector lines to link it to the appropriate target — another decision or a knowledge source.
3. **Decision Output Type** — The pulldown that maps the decision's data type to a particular part of your model or structures.
4. **Data Types Editor** — View, create, or edit the data types associated with the model.
5. **Included Models** — Reference other models so decisions, data objects, and logic can be reused.
6. **Credit Score Rating decision node** — The rectangle is a Decision Node; here it produces the Credit Score Rating from the Credit Score input.
7. **Credit Score input node** — The oval is an Input Data Node — the applicant's credit score — required to execute the decision.
8. **DRG node selector** — Navigate between the nodes of the Decision Requirements Diagram.
9. **Annotations** — Free-text annotations on the model; no executable impact, but great for explaining a model.
10. **Decision Input** — In DMN an oval represents an input; these can be mapped to specific data structures or types.
11. **Decision Node** — Places a decision on the diagram. A node with no inputs executes on invocation; if a requirement node (another decision or input) precedes it, that must complete first.
12. **Decision BKM (on the diagram)** — A Business Knowledge Model lets FEEL, Java, or PMML supplement decision execution.
13. **Decision BKM (palette)** — The palette shape for adding a Business Knowledge Model.
14. **Knowledge Source** — Documents, committees, regulations, policies, or people that define how a decision should be made. Not executable.
15. **Decision Service** — Captures decisions and exposes (or hides) them from execution.
16. **Edit Decision** — Click **Edit** below a node to edit that decision's logic.
17. **Properties of selected item** — Click the *i* icon (or press `i`) to open the selected node's properties.
* **Input Nodes**: "Applicant Data" and "Credit Score"
* **Decision Nodes**: "Loan Pre-Qualification"
* **Business Knowledge Models**: Reusable decision logic
Click on the "Credit Score Rating" decision node and select **Edit** to view the
decision logic.
This decision table is used to determine the credit ratings based on FICO®
scores. If you hover over each icon, it will describe different parts of the
Decision Table.
= 750 sets the rating to Excellent" },
{ top: 48, left: 6, label: "8. Rule 2 — FICO 700 to < 750 sets the rating to Good" },
{ top: 58, left: 6, label: "9. Rule 3 — FICO 650 to < 700 sets the rating to Fair" },
{ top: 65, left: 6, label: "10. Rule 4 — FICO 600 to < 650 sets the rating to Poor" },
{ top: 75, left: 6, label: "11. Rule 5 — FICO < 600 sets the rating to Bad" },
]}
/>
1. **Input column / condition** (e.g. "Credit Score.FICO (number)") — Sets the condition on the FICO score. The dot notation takes the `FICO` property from the input data. The rule rows below use the supplied score to determine the rating.
2. **FEEL condition** — Comparison expressions are common. Use brackets `[]` (inclusive) or parentheses `()` (exclusive) with `..` to write ranges. Note the Unique (U) hit policy requires that only a single rule can fire across the table.
3. **Output column** (e.g. "Credit Score Rating (Credit\_Score\_Rating)") — Sets the decision's output value when a row's conditions match. Here it maps to the `Credit_Score_Rating` data type.
4. **FEEL output** — The value set when the rule's conditions are met. Strings use quotes (as shown), but this could just as easily be a number or a FEEL expression.
5. **Annotations column** (optional) — Notes about each rule; ignored by the engine during evaluation.
6. **Hit Policy** (the letter in the top-left cell) — Determines how an outcome is reached when multiple rules match: Unique (U), Any (A), Priority (P), First (F), and Collect (C) variants — Collect/Sum (C+), Collect/Min (C\<), Collect/Max (C>), Collect/Count (C#).
7. **Rule 1 — Credit Score ≥ 750** — When the FICO score is 750 or greater, the Credit Score Rating is set to Excellent.
8. **Rule 2 — Credit Score 700 to \< 750** — When the FICO score is inclusive of 700 to less than 750, the Credit Score Rating is set to Good.
9. **Rule 3 — Credit Score 650 to \< 700** — When the FICO score is inclusive of 650 to less than 700, the Credit Score Rating is Fair.
10. **Rule 4 — Credit Score 600 to \< 650** — When the FICO score is inclusive of 600 to less than 650, the Credit Score Rating is Poor.
11. **Rule 5 — Credit Score \< 600** — When the FICO score is less than 600, the Credit Score Rating is set to "Bad".
In the next section, we will see how to interact with this model within Aletyx
Playground!
### Interacting With Your Decision Model
When building DMN models within Aletyx Playground, you can take advantage of the
fact that DMN includes an execution specification, making it super lightweight and
portable. Aletyx Playground includes a built-in DMN runner that lets you see how
the model would execute as it is written right now — no compilation. As you finish
your change within a given cell or decision, you can see how your decision reacts in
real time, all in the comfort of your browser!
Click the **Run** button in the top-right menu. An input form appears, allowing
you to test the decision with various inputs.
Enter a credit score between 700 and 750 to test the "Credit Score Rating"
decision.
Let's observe how the output updates in real-time as you change the input. To
test this out, edit the **Credit Score** decision by modifying a value in the
range we tested (in the GIF example this is 725, so change the second row). There
are constrained values that you can see by:
* Clicking **Data Types** at the top of the DMN model (2)
* Selecting the `Pre_Bureau_Risk_Category` and selecting `Credit_Score_Rating`
* You can see the example's prefilled values of Poor, Bad, Fair, Good, Excellent — you can either add a new value here or change to work with one of these constrained values.
Return to the model by clicking **Editor** at the top, then click the Credit
Score Rating and click **Edit**. Change the rating for scores between 700–750
from "Good" to "Excellent", and observe how the test results update immediately
after leaving the cell you are working on.
## Creating Your First Project
Now that you've explored the sample models, let's create your own project.
Return to the home screen and click **New Decision**. You can do this by clicking
the Aletyx Playground logo.
When the model opens up, you can change its name.
In your new model, you can build a DMN 1.5 model and later incorporate features
tied to a larger project that features:
* BPMN process models
* More DMN decision models
* Imported existing models
* A connection to a Git repository for version control
In the next section we will start building a new decision fairly quickly to see how
easy it is to go from Zero to DMN Hero!
## Basics of DMN modeling — A Top-Down or Bottom-Up Approach both work here!
Now that the model is created, we need to create the base of the model. Our model
can be designed from a top-down approach or bottom-up, given that we know most of
the decision as it stands right now. There is a **base level of days** that will be
used and **three extra-days cases** that can be created. We also know that there are
two inputs for the decisions — **Age and Years of Service**.
Since we know most of the decision design up front, let's get started quickly! We can
put 2 input nodes (the ovals) and four decision nodes (the rectangles) onto the DMN
designer area. You can drag and drop these from the left-hand side and start changing
the names.
This can be done by double-clicking the name of each node (double-click New Input
Data and then change the name, same with the New Decision) or by using the
properties menu — **press `i` on your keyboard when the node is selected** or click
the *i* button in the top right of the DRD editor.
```text theme={null}
Input Node 1: Age
Input Node 2: Years of Service
Decision Node 1: Base Vacation Days
Decision Node 2: Extra days case-1
Decision Node 3: Extra days case-2
Decision Node 4: Extra days case-3
```
Now that we have the names of the nodes, we need to modify the contents within them.
Click the appropriate node and click the *i* button to open the properties panel
(you can also press the `i` key on your keyboard to instantly open it). This can also
be edited using the pulldown above the node for quicker change; the properties panel
can also provide extra context if needed.
For each input node, do the following configuration:
* **Age** — Data Type: **number**
* **Years of Service** — Data Type: **number**
After this is done, we will work on the Decision nodes. Each one will have a Data
Type of number.
Everything is stored locally in the browser storage, so you don't have to press a
combination of keys to save your work as you go — the editor is constantly in motion
and saving while you're working. These are all stored locally; later we will get to
how this interaction works with Git.
Now we need to connect the Age and Years of Service input nodes to our Extra days
case-1, Extra days case-2 and Extra days case-3 decision nodes (note we're not
connecting to Base Vacation Days — this will be explained later!). A good practice with
DMN model design that Aletyx Playground allows is the use of the DMN Runner to see how
your model is evolving while you're working on it. If you **press Run** just above the
editor, you will start seeing the model interact as it changes. When your cursor hovers
over the input node (Age or Years of Service), you will see an arrow icon — the
Information Requirement arrow — that we will use to make Extra days case-1, Extra days
case-2 and Extra days case-3 all require both the Age and Years of Service inputs.
## Building Extra Days Case-1
The first Extra days case is modeled by the scenario: "Employees younger than 18 or
older than 60 will receive an extra 5 days; or greater than 30 years of service will
receive 7 days." To implement this we will build a decision table to model this logic.
Note that our decision table is going to use the Age and Years of Service that we are
taking from the input nodes.
**Click the Extra days case-1 node and select Edit** just below the box to open
the decision editor.
Set the expression type to a Decision Table and then enter the rows below.
The hit policy of the decision table is by default set to **U** (Unique), meaning
only one rule is expected to fire for a given input. Here, we want **Collect Max**:
for a given input multiple decisions might match, but we want to collect the output
from the rule with the highest number of additional vacation days. Click the **U**
in the upper-left corner of the decision table, set the Hit Policy to **Collect**,
and when prompted for the Aggregator function, **select MAX** to pull the largest
value from the table. This allows all rules to fire and the largest to be chosen.
You can test this with various scenarios using the runner while writing. You will
see these executions under Extra days case-1 on the right side of the DMN runner's
outputs.
If you add an extra row to the table after creating it, you can copy the two rows
below and paste them as you would into a spreadsheet — they're in the format you
need to work!
| Age | Years of Service | Extra days case-1 | Annotation |
| ----------- | ---------------- | ----------------- | ------------------------------- |
| `<18, >=60` | `-` | `5` | "Less than 18 or older than 60" |
| `-` | `>30` | `7` | "More than 30 years of service" |
You may have noticed situations that didn't return a value and left it `null` when
testing. To avoid issues with a null, set a default value on the output column for
the otherwise situations. Click the column header of Extra days case-1 and open the
property panel by clicking the *i* button on the decision header. Scroll down to
**Default Output Entry**. Since we're just changing the default value of the column,
no expression language is needed — just **set the value equal to 0**. Once you leave
the Content box, the decision itself reacts.
After this rule is done, click **Back to Diagram**.
## Building Extra Days Case-2
A lot of the same steps from before are going to be repeated for Extra Days Case-2,
so let's jump right in!
To implement the second use case, **click the Extra days case-2 decision node and
select Edit** to open the decision editor.
**Click on Select expression and select Decision Table.** The table will be
autopopulated with the columns, same as before, since they are connected as an
information requirement to the node.
This time the rule is an additional 4 days for more than 30 years of service, or an
additional 3 days for those greater than 60. Same as before, it will be a Collect
Max with a default value of 0. Be sure to change the Hit Policy from Unique to
Collect Max, and set the default to 0.
| Age | Years of Service | Extra days case-2 | Annotation |
| ------ | ---------------- | ----------------- | ------------------------------- |
| `>=60` | `-` | `3` | "Older than 60" |
| `-` | `>30` | `4` | "More than 30 years of service" |
After this is completed, click **Back to Diagram** so we can add the last extra days
case to Extra days case-3.
## Building Extra Days Case-3
This will be done with the case that, based on years of service being between 15 and
30, you get 3 extra days of vacation; or if at least 45 (Age), you get 2 more days.
Same as before, all default cases are set to 0.
| Age | Years of Service | Extra days case-3 | Annotation |
| ------ | ---------------- | ----------------- | -------------------------------- |
| `-` | `[15..30]` | `3` | "Between 15-30 years of service" |
| `>=45` | `-` | `2` | "Older than 45" |
This rule will be set up exactly the same way as the others. Edit the **Extra days
case-3** decision and add the conditions for between 15 and 30 years of service for 3
days, and if the Age is above 45 for 2 days. Make sure to set the default back to 0 as
before with Extra days case-1 and Extra days case-2.
Click **Back to Diagram** to return to the diagram and move to the next section.
## Summary of the Extra Days Cases
There's an important component about the three extra cases worth visiting before
moving on. You will notice that all three had both input nodes connected to them, and
from that connection the DMN editor built the columns used as condition columns, with
the decision node itself used as the output column. This greatly helps with building
your decisions. As a Decision Requirements Diagram, the decision node uses the inputs
to drive the decision based on the information requirements you give it. As we added
more components to the diagram, it continued to execute them once the requirements were
met. This is an essential part of DMN. Now that the extra days cases are each completed,
we can revisit Base Vacation Days.
## Creating Base Vacation Days
The last base decision we need to create is the **Base Vacation Days** decision. On the
base Decision Requirement Diagram, click on Base Vacation Days and click **Edit**. On the
node's "Select expression", select **Literal** and input `22`, as the base number of
vacation days is 22.
**Bringing the decisions together** — After the `22` is entered, the Base Vacation Day
decision executes as soon as it is completed. This is because this decision has no
requirements on the age or years of service. If you were to delete the data from Age
and Years of Service, Base Vacation Days would remain at 22 and the others would return
null, as the data is assumed to be null/empty. This is the power of DMN: the decisions
that can be made at the time of execution will be made based on the requirements met.
As more data is obtained (Age/Years of Service), the nodes attached to it execute once
their requirements are met. Now that we have these nodes executing, we want to reach a
final decision made when all 4 components are executed.
## Building Total Vacation Days
On the diagram, create one more decision called Total Vacation Days. Click on any of
the four decision nodes and you will see a means to add a connection to another
decision node. Click on this and drag it to an open area at the top of the Decision
Requirement Diagram.
Once this is added, connect the remaining 3 decision nodes using the line with the
arrowhead to connect them. This makes the Total Vacation Days decision require all 4
nodes to be activated before it can execute.
For this decision, it is going to be the Base Vacation Days plus the higher of the two
between case-1 and case-3, plus the days from case-2. The FEEL expression would look
like:
```text theme={null}
Base Vacation Days + max(Extra days case-1, Extra days case-3) + Extra days case-2
```
## Connecting to Git
To ensure your work is saved and versioned properly:
Click the Profile icon (👤) in the top-right corner.
Select **Git Providers** and click **Add Provider**.
Choose your Git provider (GitHub, GitLab, etc.) and configure your credentials.
Return to your project and click the **Connect to Git** button.
Select your repository and branch, then click **Connect**.
## Next Steps
Now that you're familiar with Aletyx Playground, here are some next steps to continue
your journey:
* **Design a Complete Decision Model**: Create a more complex decision model for a real-world scenario.
* **Build an End-to-End Process**: Design a complete business process with multiple tasks and decisions.
* **Deploy to Kubernetes**: Learn how to deploy your models to a Kubernetes environment.
* **Integrate with Java Applications**: Explore how to use your models in Java applications.
How decisions are authored, tested, and governed.
Orchestrate long-running business processes.
Model your first decision visually.
Background on Decision Model and Notation.
## Additional Resources
* **DMN Modeling Guide**: Comprehensive guide to decision modeling.
* **BPMN Modeling Guide**: Detailed information on process modeling.
* **Aletyx Playground API**: Learn about the API for automation and integration.