Decision Rules in Process Management

Processes are rarely strictly linear, they often involve several decisions. Complex processes can include many choices, represented using gateways in BPMN (Business Process Model and Notation) process models. However, several decisions in a process can compromise the clarity of the process model. Decision Model and Notation (DMN) provides a way to integrate complex decisions into processes. In this article, we explain what DMNs are, how they help represent operational decisions in processes and their practical applications.

What is DMN?

DMN is a standard that provides a structured way to model and standardize business decisions. By representing decision logic in a tabular format, DMNs simplify the depiction of processes with numerous decisions. This ensures greater clarity and improves the transparency of decision-making processes.

DMNs are particularly useful for automated processes, as decision engines facilitate their implementation. These engines are often integrated into many workflow engines but can exist independently. Additionally, DMNs are valuable for process documentation. While the immediate operational benefits may not always be apparent, documenting decision logic ensures standardization, traceability, and future scalability. Since DMNs integrate seamlessly with workflow engines, they can be automated effortlessly.

Structure of DMNs

DMNs are displayed in a table format, divided into one or more input columns and output columns. These columns list all possible input values, corresponding output values, and the rules governing the relationship between them.

Hit Policies

The output in DMNs depends on the hit policy applied. There are six possible hit policies, each determining how rules are evaluated and outputs are derived:

• Unique:
  • Only one rule can apply and be executed. If more than one rule applies, an error occurs.
• First:
  • The first applicable rule is executed. For instance, if rules are prioritized top-down, the first match is selected.
• Priority:
  • The result with the highest priority, defined by the sequence of outcomes or the input values in the enumeration column, is selected. For example, if “high” priority outweighs “medium” or “low,” then “Barbecue” (high priority) would be chosen over “Biriyani” (medium priority) for April 1st.

• Any:
  • All applicable rules are executed, but the outputs must be identical. If differing outputs are generated, an error occurs.
• Rule Order:
  • All applicable results are executed in the order in which the rules are listed.
• Collect:
  • All applicable results are aggregated. The outputs can be summed, counted, or the minimum or maximum value returned.

Friendly Enough Expression Language (FEEL)

DMNs use FEEL inputs. FEEL stands for “Friendly Enough Expression Language,” a user-friendly language designed to make decision modeling accessible to individuals without programming expertise. FEEL allows users to input commands and expressions intuitively. Here are some simple examples of FEEL expressions:

• age > 18: Checks if the age is greater than 18.
• income > 50000 and credit_score > 700: Evaluates multiple conditions for loan approval.
• date in [2025-04-01 .. 2025-04-30]: Checks if a date falls within April 2025.

This accessibility ensures that technical and non-technical users can collaborate effectively on decision logic.

Managing DMNs in large or complex processes can be challenging without the right tools. One solution is to use a Decision Requirements Graph, which helps visualize decision inputs and the relationships between decisions. We will explore Decision Requirements Graphs in greater detail in a separate article.

Conclusion

DMNs offer a structured and standardized approach to modeling and automating complex business decisions. By representing decision logic in a tabular format and leveraging hit policies, organizations can achieve greater transparency, traceability, and scalability. FEEL makes DMNs accessible to non-technical users, promoting wider adoption across teams.