Decision Model and Notation in Onesait Platform

Decision Model and Notation (DMN) is a standard published by the Object Management Group (OMG), a consortium dedicated to the care and establishment of different standards for object-oriented technologies.

That standard is an approach for describing and modeling repeatable decisions within organizations, to ensure that decision models are interchangeable between organizations.

The DMN standard therefore provides the industry with decision modeling notation that will support decision management and business rules. The notation is designed to be readable by both companies and IT users.

This allows several groups to collaborate effectively in the definition of a decision model:

• The entrepreneurs who manage and monitor the decisions.
• The business analysts, or functional analysts, who document the initial decision requirements and specify the detailed decision models and decision logic.
• The technical developers in charge of the automation of the systems that make the decisions.

Therefore, the DMN standard can be used effectively as a stand-alone, but it is also complementary to the Business Process Model And Notation (BPMN) and Case Management Model and Notation (CMMN) standards.

In the specific case of BPMN, a special type of activity is defined; the business rules task, which «provides a mechanism for the process to provide information to a business rules engine and to obtain the result of the calculations that the business rules engine could provide», which can be used to show where in a BPMN process a decision defined using DMN should be used.

DMN and Onesait Platform

Ever since the Platform’s 1.5.0-Defender version, we have integrated Camunda BPMN, which can be accessed from the menu Desarrollo > BPM Management.

BPMN domains are isolated instances of the BPMN engine, and there is one per each user of the Platform. The instance is created when the user logs in for the first time. This level of isolation allows for a more efficient implementation and management of processes.

What does this imply? This: If you implement a process that specifies a domain (although that is not mandatory), this process will only be visible to you, to users with the Administrator role and to users that you explicitly authorize. On the other hand, processes without a domain will be visible to any user.

If you are interested in knowing more about how all this works, we have described some first steps in our Developer’s Portal.

Practical example

Say we have the following example decision table:

In a BPMN, if we didn’t use those, we would have to use gateways like the ones we see in the following diagram..

That’s why BPMN includes the so-called business rules task, which should be called decision task in a later version of the BPMN standard: That task refers to a decision that must be made, and the result of the decision allows the subsequent exclusive gateway to route the flow, as you can see below.

During modelling and execution, we can link the «Choose Activity» task to the DMN decision table, which will be executed when the decision must be made, and the result will determine the additional flow in BPMN.

In this particular example, you might wonder about the use of flow routing at all. There are six tasks related to the preparation of an activity, the only difference being the activity. There is no apparent advantage in having those six different tasks. An alternative pattern would be as follows:

In this case, we see how flow is quite simplified by using DMN and we can conclude that combining BPMN with DMN is a good approach.

Interesting? Well, if you liked it, next week we will bring you another article about DMN where we will describe a practical example of how to upload the DMN tables and use them in our BPMN. We’ll be waiting for you!

✍🏻 Author(s)