BPM6.

Decision Modelling
with DMN

Prof. Dr. Jochen De Weerdt

Lecture overview
1. Process modelling and decisions
2. Decision Model and Notation (DMN)
3. Decision requirements modelling
4. DMN decision logic
5. Decision tables
6. Expression language for decision logic (FEEL)
7. Conclusion
2
Supporting lecture material
• Milani, F., (2019) Digital Business Analysis. Springer.
• Chapter 15
• Section 15.2
• Section 15.3

• Dumas, M., La Rosa, M., Mendling, J., Reijers, H. (2018)

Fundamentals of Business Process Management.
• Chapter 10 (10.5.8)

• DMN 1.3 specification (https://www.omg.org/spec/DMN)

3
1. Process modelling and decisions

4
What should be in a process model?
Exceptions?
Timers?
Happy path?
Decisions?
Decision logic?
Business rules?
Roles?
Messages?
Notifications?
Triggers?
Conditions?
…

5
What to model?
• Decisions are important for business, not only processes
• Why would we only model the processes?
• Where is the decision?
• How is the decision logic modelled?
• Model the decision activity: Decide acceptance

?
6
What to model?
• Processes contain decisions
• When to accept/refuse a claim? Depends on:
• Customer history
• Format requirements
• Timing constraints
• Type of contract
•…
?

7
Decisions come in many forms
• Strategic and tactical decisions
• Often high-level, long-term, big impact, infrequent,
unstructured Strategic decisions
• Do we enter the insurance market?
• Should we sell travel insurance?

• Operational decisions
Tactical decisions
• Daily, high-volume, often structured, standard • Which products will we promote?

procedures • How to measure and manage

performance?

• Mathematical (and analytics) models, or

• Standard operating procedures Operational decisions
• Based on company rules, policies and regulations • How to handle routine cases?
• Follow known rules
• Present in operational business processes

• E.g.: eligibility, price, insurance, discount, theft rating, customer offer,

retention, supplier selection, hire, credit, …

8
Operational decisions
• Made frequently
• Non-trivial
• Made rapidly
• Made consistently
• High volume
• Measurable business impact
• Deterministic
• Frequent change (but compliant)
• Comprehensibility
• Automated or manual

9
Managing decisions
• What is the decision?
• eligibility, price, insurance, theft rating, customer offer, retention, supplier
selection, hire, credit, …
• Who, what, how?
• Who owns the decision?
• Who makes the decision every day?
• Who is impacted?
• What triggers the decision?
• When are we making this decision?
• What is required to make this decision?
• Information requirements
• Knowledge sources (regulations, analytics, expertise)
• Other decisions
• Decision logic

10
Decisions in processes
1. Inside a knowledge-intensive activity
• Manual or automated

(random Google picture)

11
Decisions in processes
2. Or as shown by a simple gateway
• Based on a single question (criterion) with
two or more outcomes
• Note: the gateway itself is not the decision

(random Google picture)

(random Google picture)

12
Decisions in processes
3. Or as shown by a cascade of gateways
• Based on multiple questions (criteria)

(random Google picture)

13
The wrong way
• Decision trees should not be process
paths
• Do not hardcode decision rules into the accept low risk
applicant

process model Age<20

Bad Medical Record
refuse high

• Separating (decision) rules from the

risk applicant

process simplifies the process 21<=Age<50

• Simplify nested decision paths Good MedicalRecord

accept
medium risk
applicant

• Decide applicant type

• Applicant type depends on Age (and in some cases also Age>=50

Medical Record)

14
Separate the business rule from the
process

Rules to decide the routing

15
Acknowledged in BPMN 2.0
New BPMN 2.0 Activity Types

applicant process high

risk applicant
type rules Highrisk

determine process
applicant medium risk mediumrisk
ty pe applicant
16
Decisions need to be modelled
• Decision models are not
lower level details of one
process
• Decisions models can span
over multiple activities, and
even multiple processes
• Separation of concerns

17
Decision and Process Model

18
Decision and Process Model

19
The need for DMN
• Decision(s) (rules) need to be
modelled
• DMN decision models are meant to
be created by the business, not IT
• A standard for processes (BPMN) is
not enough

→ Decision Modeling & Notation

standard (DMN)

20
2. Decision Model and
Notation (DMN)

21
Decision Model and Notation
• The DMN (Decision Modeling & Notation) standard was produced by OMG (version 1.0 in
2014, version 1.3 in 2021): https://www.omg.org/dmn/

• DMN is a modeling language and (executable) notation for the precise specification of
business decisions and business rules

• DMN is easily readable by the different types of people involved in decision management
• business analysts who create initial decision requirements and detailed decision models
• businesspeople who specify the rules, and manage & monitor their application
• technical developers responsible for automating the decisions in processes

• Interchangeable across tools/organizations via an XML representation

22
Decisions as a business concern
• More and more business operations are being automated
• Business has to react immediately, e.g. in online applications
• A human is often not involved anymore at the moment of
transaction

• It is important that systems, processes and decisions are

crafted correctly and remain correct after updates

23
Decision automation
• DMN unifies modelling and execution
• DMN models can be (directly) automated using a Business
Rules Management System (BRMS)
• Decision service
• Encapsulation of the decision logic
• Provisioning of an interface
• When called with a set of input data, the decision service will evaluate
the specified decisions and return their results

24
Consistent and explainable decisions
• Automated systems and processes contain the logic of
decisions
• In automated decisions the decision logic should be:
• well-designed
• correct
• consistent
• explainable
• understandable by the business
• easy to change
• maintained by the business

25
DMN: Two modelling levels
• The Decision Requirements level
• What is required to make this decision?
• Information
• The outcome of other decisions
• Knowledge sources (regulations, analytics, expertise)

• The Decision Logic level

• How is the outcome of the decision determined?

26
DMN in two pictures
1. Decision requirements 2. Decision logic

Applicant Risk Rating

U
Applicant Age Medical History Applicant Risk Rating
1
good Medium
> 60
2
bad High
3
[25..60] - Medium
4
good Low
< 25
5
bad Medium

27
Decision tables
• Good decision table models are a proven technique to represent
decision rules
• Consistency, completeness and correctness by design

Applicant Risk Rating

U
Applicant Age Medical History Applicant Risk Rating
1 good Medium
> 60
2 bad High
3 [25..60] - Medium
4 good Low
< 25
5 bad Medium

28
Example: Covid Safe Ticket

29
Major elements of DMN
• Decision Requirements Diagram (DRD)
• What do we need to make a decision: goal
oriented requirements

• The decision rules

• The logic behind each decision

• The FEEL (Friendly Enough Expression

Language) expression language
• How to define functions, operators and
expressions
30
3. Decision requirements modelling

31
Why decision requirements modeling?
• The decision requirements level describes WHAT we need in order to
make a decision, not HOW to make it :

• What is required to make a decision?

• Information
• The outcome of other decisions (is also information)
• Knowledge sources (regulations, analytics, expertise)
• Knowledge (the decision logic)

• This is a goal-oriented description of the decision

• The top decision is the goal

32
Decision requirements notation
• A decision depends on criteria, input data, decision rules,
etc. Notation Example
• The decision requirements diagram (DRD) models these Decision Discount
dependencies using only a few symbols
• A box represents a decision
• A rounded rectangle represents the required information to make
the decision. Decision Customer Type

• A full arrow line represents an information requirement

• A decision can also depend on the outcome of another
decision Information Customer data

• That is also an information requirement

• E.g. A rule might state that if the customer type is A, the discount is
0, where customer type is also a decision with its own data, logic,
etc.

33
When does a decision depend on another
decision?
• In a car rental company, a rental is offered or refused depending on
age eligibility, drop-off validity and availability of the requested
vehicle.
• A vehicle is available if the requested car group is available OfferOrRefuse

(AsRequested) or if an update group is available (Upgrade).

VehicleAvailability

• VehicleAvailability shows the dependency

• It is a requirement in the first sentence (if available) Fleet data
• And a conclusion in the second sentence (available if)

• If an information item is a conclusion in one place, and a condition

in another, then it is the source of a dependency.

34
DMN basic components
• A decision is the act of determining an output value (the chosen option),
from a number of input values, using logic defining how the output is
determined from the inputs
• This decision logic may include one or more business knowledge models
which encapsulate business know-how in the form of business rules,
analytic models, or other formalisms

35
Knowledge sources
• Authorities may be defined for decisions or business knowledge models
• They might be (for example) domain experts responsible for defining or
maintaining the knowledge model, or source documents from which
business knowledge models are derived, or sets of test cases with which
the decisions must be consistent
• These are called knowledge sources

36
Decision Requirements Diagram
• A decision is said to “require” its inputs in order to
determine its output
• The inputs may be input data, or the outputs of
other decisions
• If the inputs of a decision Decision1 include the
output of another decision Decision2, Decision1
“requires” Decision2
• Decisions may therefore be connected in a network
called a Decision Requirements Graph (DRG), which
may be drawn as a Decision Requirements Diagram
(DRD)

37
Summary

38
Summary

39
Example of a DRD (1)

Information requirement

Knowledge requirement

Authority requirement

40
Example of a DRD (2)

41
What to do, or how to do it?
• What is to be decided? Possible outcomes?
• Decisions require:
• Input data
• Transactions
• Master data
• External data
• Decision logic
• Rules, knowledge
• Policies
• Analytics
• Outcome of other decisions
• Reusability

42
Advantages of decision requirements
modelling
• Why is it so important to separate the decision structure from the
decision logic?

• The Decision Requirements Diagram (DRD) focuses on the big

picture,
not the details of the decision rules
• It enables to split the decision in subdecisions
• It avoids the ‘big bucket of rules’
• It allows to update the rules without changing the structure
• It allows reuse of subdecisions
• It is declarative in nature
• E.g. if a decision requires two subdecisions, the DRD does not
impose an execution order

43
4. DMN decision logic

44
Decision logic
• Using decision logic, the decision components of a DRD may be
specified in greater detail, to capture a complete set of business
rules and calculations, and (if desired) to allow the decision-
making to be fully automated
• At the decision logic level, every decision in a DRG is defined
using a value expression which specifies how the decision’s
output is determined from its inputs.
• At that level, the decision is considered to be the evaluation of
the expression. The value expression may be notated using a
boxed expression

45
Decision logic as boxed expressions

46
Three basic expression types
• Decision tables: logic based on rules

• Literal expressions: formulas such as arithmetic

• Invocations: leveraging decision logic from elsewhere (e.g.

BKM)

47
How to write decision logic?
• Natural language
• Unclear, ambiguous

• Logic
• Powerful, unambiguous, but not for business people

• Structured English Rules

• Subset of natural English
• Trade-off between ease of use and powerful

• Decision trees, tables, graphs, diagrams

• Different representations for different purposes: acquisition, V&V, decision making, dependencies,
impact analysis

• Object Constraint Language

• Part of UML
• Useful for pre- and postconditions

48
How to write decision logic?
• A decision or business knowledge model may contain any decision logic
which is capable of being represented as a function

• This will allow the import of many existing decision logic modelling
standards (e.g., for business rules and analytic models) into DMN

• An important format of decisions/business knowledge models, specifically

supported in DMN, is the Decision Table

49
Decision logic as a decision table

50
5. Decision tables

51
Elements of a decision table in DMN

Name of the Information item

decision (= the
output item)

Hit policy
indicator Name of information item
Possible values

Rule numbers Values (value expressions)

(rules in rows) e.g.:
= US, < 20, false, [10..20]

“-” means:
irrelevant in
this rule

Inputs Outputs

“-” means: does not matter in this rule (irrelevant)

52
Decision table are not new

53
Why decision tables?
• Problems with lists of rules:
• The order of information items is not the same in all rules
• The name of information items is repeated in many rules
• Connectors can be and, or, with parentheses, etc.
• Rules are complex, hard to understand and hard to validate

• Decision tables will solve these problems

• Order of information items will be the same in all rules
• The name of information items is only written once
• Connectors will only be AND
• The collection of rules will be easy to validate
54
Hit policies
• Single hit (return 1 rule with outcome(s))

• Default:
If rules are non-overlapping: unique hit

• Recognize others:
If rules are overlapping, then 1 rule has to be selected:
any hit, first hit, priority hit

• Multiple hit (return a list of rules)

55
Hit policies
Applicant Risk Rating

Hit policy

Inputs Outputs

• Hit policy:
• If one rule is required:
• Unique (if there is only one for every set of inputs) [default]
• Or select the desired one: Any, First, Priority
• If all applicable rules are required:
• Results in an output list (operations may be applied, e.g. sum(partialscores))
• List order is No order (arbitrary), Rule order, Output order

56
DMN Types of tables (Single hit)
• DMN identifies different table types, indicated by the first letter
Good
• Unique hit tables: every input case is included in one rule only. There is no overlap between
rules.
Ugly
• Any hit tables: every input case may be included in more than one rule, but the outcomes
are equal. Rules are allowed to overlap.

• Priority hit tables: multiple rules can match, with different outcome values. This policy
returns the matching rule with the highest output value priority (e.g. highest discount). The
priority order is determined by the order of listed output values in the output column
heading.

• First hit tables: multiple (overlapping) rules can match, with different outcome values. The
first hit by rule order is returned (and evaluation can halt). This is a common usage,
because it resolves inconsistencies by forcing the first hit. It is important to distinguish Bad
this type of table from others because the meaning depends on the sequence of the rules.
Because of this sequence, the table is hard to validate manually and therefore has to be
used with care.

57
Example decision logic
Strategy
(U) Pre-Bureau Eligibility Bureau Call Type Strategy
1 INELIGIBLE - DECLINE
Strategy 2 ELIGIBLE FULL, MINI BUREAU
Bureau Call Type
(U) Pre-bureau risk category Bureau Call Type 3 NONE CONTINUE

1 HIGH, MEDIUM FULL table with unique columns - complete

2 LOW MINI
3 DECLINE NONE
table with unique columns - complete

Pre-Bureau Eligibility
Bureau Pre-bureau
P Pre-Bureau risk category Instalment Affordable Age Monthly Income Pre-Bureau Eligibility
call type eligibility
1 DECLINE - - - INELIGIBLE
2 - False - - INELIGIBLE
3 - - < 18 - INELIGIBLE
4 - - - < 100 INELIGIBLE
5 - - - - ELIGIBLE
table with overlapping columns (priority INELIGIBLE > ELIGIBLE)

Pre-Bureau Risk Category

Existing Customer Application Risk Score Pre-Bureau Risk Category
True <100 HIGH

Pre-bureau [100..120] MEDIUM

risk category > 120 LOW
False < 80 DECLINE
[80..90] HIGH
(90..110] MEDIUM
> 110 LOW
single hit - consistent - complete - non redundant

58
Unique hit decision tables
Applicant Risk Rating
U Applicant Risk
Applicant Age Medical History Rating
1 good Medium
> 60
2 bad High
3 [25..60] - Medium
4 good Low
< 25
5 bad Medium

Medical History
Applicant Risk Rating Applicant Risk Rating
good bad
Applicant Age < 25 [25..60] > 60
< 25 Low Medium
Medical History good bad - good bad
Applicant Risk Applicant Age [25..60] Medium Medium
Low Medium Medium Medium High
Rating
U 1 2 3 4 5 > 60 Medium High

Applicant Risk Rating

Applicant Age < 25 [25..60] > 60

goo
Medical History bad - good bad
d
Low X - - - -
Medium X X X
High X
U 1 2 3 4 5 59
Why different types of tables?
• Two guiding principles
• The simpler the better, and fewer rules is simpler
• The rules should make the underlying logic as easily understood as
possible

• Comparison
• U tables often typically require more rules, but are less error prone
• A tables can make the underlying logic (relation input to output) more
easily understood
• P tables might be convenient when decision inputs have many
enumerated values, however they sometimes obscure the logic
60
Decision table validation
• What makes a good decision table?
• Completeness
• There should be no combination of allowed input values that does not match at least one rule
• Consistency
• In a U table, rules should not overlap
• In an A table, overlapping rules should have the same output value
• In a P table, no rule should be “masked” (appear below a rule that would always hit)
• Avoid subsumption
• Decision tables should not contain two or more rules that could be combined
• Apply decision table contraction

61
6. Expression language for decision
logic (FEEL)

62
Expressing the Decision Logic
• FEEL (“Friendly Enough Expression Language”) implements the required
mechanisms
• Built-in types, functions and operators S-FEEL note

• Every decision in a DRD can be defined using a formal expression High = “High”

that specifies how the decision’s output is determined from its inputs Risk Rating variable

• Complete decision models can be defined Customer.name variable

2016-02-02 date literal
• Formal expressions may also be encapsulated as functions
[1..10) range
• Supports abstraction, composition, and scalability
Age < 45 comparison
payment / months expression
• S-FEEL (“Simple FEEL”) is a basic subset of FEEL designed
to cover the essential requirements of Decision Table
based DMN models

• DMN can be extended to use other expression and type definition languages

63
FEEL
• Similar to functions in Excel
• Just an expression language that calculates values
• Useable by businesspeople

• To make DMN decision models executable, FEEL is a key

requirement
• DMN models are not merely business requirements handed off to
programmers
• You can execute the model right in a modelling tool
• You can deploy it in a cloud service

64
Conformance
Conformance

 Level 1  Level 2
Notation,
Notation, Interchange

Interchange
+ S-FEEL

 Level 3
Notation,
Interchange

+ FEEL

65
6. Conclusion

66
Issues DMN solves
• Separating decisions and processes
accept low risk
applicant

Age<20
refuse high
Bad Medical Record

• Using a standard modelling notation.

risk applicant

21<=Age<50

accept
Good MedicalRecord medium risk
applicant

Age>=50

67
Issues DMN solves
• Separating decision structure and decision logic
• Allows to model decision relations, even if not all logic is expressed in
tables

68
Issues DMN solves
• Decision modelling methodology
• Keep the insights of the past and avoid confusion
• Good decision table models are a proven technique to represent
decision rules
• Consistency, completeness and correctness by design

69
Issues DMN solves
• Decision table types
• Recognize, and unambiguously exchange
• DMN allows multiple table types (good for exchange)
• Unique hit, Any hit (like in some methodologies), First hit (like in some tools), Multiple hit, …
• Good decision table models are much stricter
• Decision table methodology is a methodology, DMN is not

• There is nothing new in DMN about decision tables, but DMN allows to
standardize and recognize other decision table formats and avoids
ambiguity about the concept.

70
Application areas & tools
• Decisions, decisions, decisions
• Decisions in process modelling
• Process variability

• “Simple” operational decisions

• Eligibility, credit, churn, social security, finance,
insurance, healthcare, security, definitions, …
• Regulations, legislation

• Enumerating and evaluating alternatives,

constraints
• Combinatorial optimizations
• Scheduling and resource allocation

71
Signavio

72
What should you know and what should
you be able to do?
• You should know:
• what the major elements are in DMN
• how to model decision requirements
• how to model decision logic in DMN
• what decision tables are, which types exist, and which criteria are important to validate
decision tables
• what an expression language entails, why it is important, and how FEEL is the
expression language for DMN
• You should be able to:
• build and analyse decision tables
• identify types of decision tables

73