Introduction
When we discuss whether a workflow should become a case type (instead of a flow or subflow), we usually start with familiar questions:
- Is it a business outcome on its own?
- Does it need dedicated SLAs?
- Does it have multiple stages or milestones?
- Do we need traceability or auditability?
All of these are valid — and necessary.
But over time, one perspective has become the first one I personally value as a solution designer:
Do we need specific performance and progress reporting for this work? Is there anyone in the business who is tasked with improving this specific KPI ?
Why I put reporting at the center
In my experience, reporting expectations tend to surface late — often after go‑live — when the business starts asking questions like:
- “Why does this step take so long?”
- “Where are we blocked?”
- “Which part of the process should we optimize first?”
All of these questions are perfectly valid concerns to improve business operations.
At that point, whether something is a case type or “just a flow” suddenly matters a lot.
A case type gives you first‑class visibility:
- lifecycle‑level progress tracking
- completion time and backlog monitoring
- KPIs that can be analyzed and improved independently
A flow or subflow can work perfectly from an execution standpoint, but it often limits how explicitly this work can be measured and optimized. Moreover, it has less “flexibility” and out-of-the-box tooling (reporting, integration, AI, etc.).
Concrete example
Take a claims process as a main case type.
Document review and manual approval are often modeled as simple flows.
That can be perfectly fine — unless the organization wants to:
- monitor review cycle time,
- identify approval bottlenecks,
- compare performance across teams or regions,
- continuously improve document handling efficiency.
In that situation, introducing dedicated sub‑cases for document control and approval becomes very attractive — not because of hierarchy or reuse, but because those workflows become measurable, visible, and optimizable on their own.
Tradeoffs I still keep in mind
- Not every measurable step deserves its own case type.
- Too much decomposition can add cognitive overhead.
- The goal isn’t more reporting — it’s meaningful reporting that drives action.
But when performance really matters, I’ve found that modeling choices either enable or block improvement later on.
In the end,
When deciding between a case type and a flow, how much weight do you give to reporting, KPIs, and performance optimization?
Is it a primary driver in your designs, or something you address later?
Curious to learn how others approach this trade‑off. When would you not design a specific case type when you have strong reporting requirements ?
(English is not my native language - GenAI helped me reformulate my ideas)