“First we do this, then we wait for that”
You are probably describing a process. Use BPMN-based modelling when the normal route and its exceptions can be made explicit.
Read the BPMN guideA plain-English guide
BPMN, CMMN and DMN solve different parts of the problem
BPMN describes the route. CMMN holds work that changes with the situation. DMN describes the rule used to reach a decision. Most organisations need more than one, and the useful question is where each belongs.
Repeatable route
Changing situation
Explicit rule
The short answer
Start with what makes the next step happen
| Model | Use it when | What it makes visible |
|---|---|---|
| BPMN-based process | A defined route, event or result determines what happens next | Activities, events, gateways, waits and responsibility |
| CMMN-based case | New evidence or professional judgement determines what work is appropriate | Case information, available work, planning and milestones |
| DMN-aware decision | Known inputs should produce a result through explicit rules | Inputs, rule logic and outputs |
One example
Consider a serious customer complaint
The complaint itself may need a case because the facts, people involved and appropriate response are not known at the start. The case keeps the evidence and gives an authorised person suitable work to choose from.
Some parts are repeatable. A privacy check, acknowledgement or refund approval may follow a defined process. Those parts can run as BPMN-based processes from the case.
A rule may decide whether the complaint must be escalated. That logic belongs in a decision, where the inputs and outcome can be reviewed without tracing the whole process or case.
How to choose
Listen to how people describe the work
“It depends on what we find”
You are probably describing a case. Use CMMN-based case management when evidence and judgement change the work that should happen next.
Read the CMMN guide“These are the rules we apply”
You are probably describing a decision. Use a DMN-aware model when known inputs should produce an explicit result.
Read the DMN guideUsing all three
Connect the models at clear points
The models are easier to understand when each one has a limited job.
- 1
Open the case
Start the work as a case because the final route depends on what is discovered.
- 2
Collect evidence
Add documents, facts and events to the case record.
- 3
Run a standard check
Invoke a repeatable sequence for retrieval, validation and human review.
- 4
Apply the rule
Use the known inputs to produce a routing or escalation result.
- 5
Choose the next work
Return to the case, where the result becomes part of the situation an authorised person considers.
Where models go wrong
A bigger diagram is not always a better answer
Many modelling problems begin by asking one notation to carry everything.
A process becomes hard to maintain when dozens of gateways try to predict every professional judgement. A case becomes vague when repeatable checks are left as manual instructions. A decision becomes difficult to govern when the rule is buried inside routing lines or application code.
Keep each model small enough to explain. Connect them where a process task, case task or decision task has a clear input and result.
Too many gateways
The process is trying to imitate judgement that belongs in a case.
Too much manual work
The case is repeating steps that should be a published process.
Rules nobody can find
The decision is hidden in code, conditions or informal guidance.
How this works in Pūnaha
Separate models, connected execution
Published definitions
Processes, cases and reusable workflows have controlled versions, so running work remains tied to the definition it started with.
Process and decision tasks
A case can invoke repeatable work or defined decision logic and bring the result back into the case.
Human tasks
Execution can wait for an authorised person when approval or judgement is required.
Knowledge and AI
Retrieval and supported AI models can appear as visible steps rather than hidden behaviour.
Durable state
Supported waits, events and case lifecycle state remain available beyond one browser session.
Execution history
The result can be viewed in the context of the process run or case in which it was used.
Questions people ask about the three models
Can one solution use BPMN, CMMN and DMN?
Yes. A case can call a repeatable process and a decision. The important part is to give each model a clear responsibility.
Does CMMN replace BPMN?
No. CMMN-based cases suit evolving work. BPMN-based processes suit repeatable work. They are often most useful together.
Does DMN define the workflow?
No. DMN describes decision logic. BPMN describes process flow, and CMMN describes adaptive case work.
Does Pūnaha claim formal standards conformance?
No. Pūnaha provides supported standards-aware modelling and interchange, but this site makes no formal BPMN, CMMN or DMN conformance or certification claim.
Bring work that never fits the neat flowchart
We can separate the repeatable route, the changing case and the decision rules, then show how they work together.