Skip to main content
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. No installation required — just start playing immediately!

​
The Aletyx Playground Interface

When you navigate to Aletyx Playground, you’ll see a welcome screen with several key areas:
Aletyx Playground Welcome Screen
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.
1

Open the sample

From the welcome screen, click Try Sample under the Decision section.
Try Sample DMN
2

Review the model

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.
Sample DMN Model
3

Explore the model components

  • Input Nodes: “Applicant Data” and “Credit Score”
  • Decision Nodes: “Loan Pre-Qualification”
  • Business Knowledge Models: Reusable decision logic
4

Open a decision

Click on the “Credit Score Rating” decision node and select Edit to view the decision logic.
Edit Credit Score Rating
5

Inspect the decision table

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.
  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!
1

Run the model

Click the Run button in the top-right menu. An input form appears, allowing you to test the decision with various inputs.
Run DMN Model
2

Test an input

Enter a credit score between 700 and 750 to test the “Credit Score Rating” decision.
3

Observe real-time output

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.
DMN Enumeration
4

Modify the decision table

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.
DMN Testing

​
Creating Your First Project

Now that you’ve explored the sample models, let’s create your own project.
1

Create a new decision

Return to the home screen and click New Decision. You can do this by clicking the Aletyx Playground logo.
New DMN Decision
2

Name the model

When the model opens up, you can change its name.
Create Project
3

Plan the project

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.
DMN nodes on DRD showing modeling
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.
Property change
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.
Age with Information Requirement Arrow
Demo of the process

​
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.
Demo of Extra Days
1

Open the decision editor

Click the Extra days case-1 node and select Edit just below the box to open the decision editor.
2

Set the expression type

Set the expression type to a Decision Table and then enter the rows below.
3

Set the hit policy

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!
4

Set a default output

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.
Demo of Extra Days
5

Return to the diagram

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!
Demo of Extra Days
1

Open the decision editor

To implement the second use case, click the Extra days case-2 decision node and select Edit to open the decision editor.
2

Select a decision table

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.
3

Enter the rules

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.
4

Return to the diagram

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. 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.
Demo of Extra Days
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.
Base Vacation Days
Demo of Base Days
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

1

Add the decision node

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.
Demo of Total Vacation Days
2

Connect the remaining nodes

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.
3

Enter the FEEL expression

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:
Demo of Total Vacation Days

​
Connecting to Git

To ensure your work is saved and versioned properly:
1

Open Profile

Click the Profile icon (👤) in the top-right corner.
2

Add a Git provider

Select Git Providers and click Add Provider.
3

Configure credentials

Choose your Git provider (GitHub, GitLab, etc.) and configure your credentials.
4

Connect your project

Return to your project and click the Connect to Git button.
5

Select repository and branch

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.

Decisions guide

How decisions are authored, tested, and governed.

Processes guide

Orchestrate long-running business processes.

Decision Analyst quickstart

Model your first decision visually.

What is DMN?

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.