Here is the honest version of the confusion I keep seeing: a team has a process that keeps breaking, escalating, and producing exceptions that the workflow tool cannot handle. Someone on the engineering side suggests BPM. Someone on the ops side says they heard about adaptive case management. Three weeks later, they have bought a new tool that does roughly the same thing as the old one, and the exceptions are still being handled in email threads.
The confusion is real and the cost is real. BPM and adaptive case management are not the same model. One is built for processes where the path is known in advance. The other is built for situations where the path cannot be known in advance, because the work itself determines what happens next. Buying BPM for the second kind of problem is like buying a map for a terrain that has not been charted yet.
This article explains what adaptive case management actually is, where the two models genuinely diverge, and how to decide which one your situation actually calls for.
The part teams learn too late
- ACM is not a BPM upgrade - it is a different coordination model built for work where the path cannot be defined in advance.
- The case, not the workflow, is the core unit: a container that evolves as new information arrives.
- Knowledge workers control the path in ACM; the system supports their decisions rather than constraining them.
- ACM is used across finance, healthcare, government, HR, and legal - not just in regulated industries.
- Structure still exists in ACM - but it comes from milestones and rules, not from a predetermined sequence.
What Adaptive Case Management Actually Means
Adaptive case management (ACM) is an approach to coordinating knowledge-intensive work where the sequence of tasks, the decisions made, and the people involved cannot all be specified before the work begins. The system supports the worker's judgment rather than replacing it with a fixed path.
The standard workflow automation model assumes you can draw the process before it runs. Trigger fires, steps execute, outcome delivers. That model works well when the process is the same every time. Adaptive case management is built for the opposite situation: work where each instance is different, where new information changes what needs to happen next, and where forcing everyone down a predetermined path produces worse outcomes than letting the knowledge worker decide.
A case in this context is not a support ticket or a legal file in the narrow sense. It is any unit of work that requires coordination, judgment, and adaptation over time. A complex customer complaint. A fraud investigation. A patient care plan. An HR disciplinary matter. The case holds all the content, task history, decisions, and context together in one place, and it evolves as the situation develops.
"Dynamic case management" and "advanced case management" are alternative names for the same concept. The terminology varies by vendor and industry, but the ACM approach underneath is the same: give knowledge workers a flexible, non-linear environment to manage work that cannot be fully modeled as a linear process. Whatever the label on the product box, if the management approach centers on cases rather than fixed flows, you are in the same territory.
![]()
The Core Problem ACM Solves - Work That Cannot Be Modeled as a Linear Process
Most workflow automation tools make a quiet assumption: that someone, somewhere, has already thought through every meaningful path the work could take. The process is modeled. The exceptions are handled. The edge cases are branches in the diagram. You configure the tool, and then the process runs.
This assumption holds reasonably well for structured processes. An invoice approval flow. An employee onboarding checklist. A ticket-to-close sequence in a support queue. These are predictable enough that the design effort pays off.
But a large category of knowledge work is genuinely unpredictable. Not just complex - unpredictable. As Flowable and similar platforms in this space have put it: there are business scenarios where both the path and the outcome cannot be fully defined in advance, because the work itself changes based on what is discovered along the way. A fraud analyst looking at a suspicious transaction cluster does not follow a script. A healthcare social worker coordinating discharge for a patient with multiple comorbidities and complicated housing is not executing a checklist. A legal case manager handling a matter that touches three jurisdictions is not filling in a form.
When you try to force that kind of work into structured processes, one of two things happens. Either the process model becomes so exception-heavy that it is essentially unmanageable, with hundreds of conditional branches that nobody maintains. Or the workers learn to route around the tool entirely, falling back to email, spreadsheets, and Slack threads to handle anything the workflow cannot accommodate.
That is the operational symptom of the mismatch: work happening outside the system, with no audit trail and no shared context.
The design problem ACM addresses is not "how do we make the process better." It is "how do we support workers whose job involves handling genuinely complex business scenarios that change as they unfold." That is a different problem, and it requires a different approach.
What Makes a Case Different From a Standard Business Process
A standard business process is a sequence. A case is a container.
The case file - sometimes called a case folder - holds everything relevant to a single instance of work: the incoming documents, the tasks that have been assigned and completed, the decisions that have been made, the communications that have occurred, the business rules that have been applied, and the current status. New information arrives and is added to the case data. The case evolves rather than advancing through fixed stages.
According to KMWorld's research on case management, a mature ACM approach orchestrates workflow, content management, business rules, portal access, and collaboration tools across the entire case lifecycle - all anchored to the case record rather than to a process diagram. That is a meaningful distinction. The workflow is a feature of the case, not the frame that contains everything else.
This matters practically. When a new document arrives and changes what needs to happen, a process model requires someone to update the diagram. A case model just adds the document to the case and lets the worker decide what it means for the next steps.
How Business Rules and Milestones Keep Cases From Becoming Pure Improvisation
The most common misconception about adaptive case management is that removing predetermined sequences means removing structure entirely. It does not.
ACM uses business rules and milestones to provide the structure that matters without constraining the steps that vary. Milestones define what states the case needs to reach - investigation opened, evidence reviewed, decision issued - without specifying the exact path between them. Business rules trigger event-driven actions when certain conditions are met: a document arrives and triggers a notification, a deadline passes and escalates the case, a risk threshold is crossed and requires approval.
The difference from BPM is not the absence of rules. It is where the rules sit. In BPM, the rules define the sequence. In ACM, the rules respond to case events without dictating the order in which tasks are performed. Workers can add ad hoc tasks, skip steps that are not relevant to this specific instance, and restructure the work as new information arrives - all within a framework that still enforces the compliance and governance requirements that cannot be flexible. You do not need to predefine every action to maintain accountability. That combination is what makes the model useful for genuinely complex work.
Adaptive Case Management vs. Business Process Management - Where the Models Diverge
The comparison between ACM and BPM comes up constantly in support conversations, and it almost always starts from the same wrong framing: that ACM is a more advanced or more flexible version of BPM. It is not. These are models built on different assumptions about the nature of the work they are trying to support.
The table below captures the practical dimensions where the two diverge. After the table, I will note the one row that deserves more than a cell can hold.
| Dimension | BPM | Adaptive Case Management |
|---|---|---|
| Process predictability | High - paths are defined before execution begins | Low to medium - paths emerge as the case unfolds |
| Who controls the path | The process model designer | The knowledge worker handling the case |
| Handling of exceptions | Requires explicit modeling of each exception branch | Ad hoc changes are a first-class feature, not an exception |
| Improvement model | Optimize predefined sequences over time | Learn from case outcomes to evolve practice (ArkCase describes this as building a learning organization) |
| Best-fit work type | Repetitive, structured processes with predictable paths | Dynamic processes where outcomes and paths cannot be fully defined in advance |
The improvement model row is worth expanding. BPM gets better when you optimize a known sequence: reduce cycle time, eliminate waste, standardize outputs. ACM processes improve differently. Each resolved case becomes a data point. Patterns across cases reveal better practices, better decision rules, better escalation triggers. ArkCase describes this explicitly as ACM aiming to turn organizations into learning organizations, where the case history is itself a knowledge asset. That is not a feature you add to BPM. It is a different frame for what process improvement means.
A practical note for business process management evaluation: BPM and ACM are not always in competition. Predictable subprocesses - document assembly, notification routing, SLA tracking - can run as structured BPM flows inside a larger ACM case structure. The case layer handles the judgment work. The BPM layer handles the repeatable parts. When someone tells me they are choosing between the two, I usually ask whether they actually need to choose, or whether their work has both predictable and unpredictable layers that each need a different tool underneath.
Where Adaptive Case Management Is Used Across Industries
One of the more durable misconceptions about ACM is that it belongs to legal and healthcare and nowhere else. This comes from the fact that legal casework and clinical care pathways are the most frequently cited examples in the literature. But the applicability is much broader than that. Any domain where knowledge workers manage complex, multi-stakeholder situations with variable paths and real accountability requirements is a candidate for ACM approaches.
The i-SCOOP editorial analysis on case management makes this cross-domain applicability explicit: ACM is well-established in finance, insurance, government services, HR, investigations, legal, and healthcare. What these domains share is not their industry - it is the nature of the work. Cases that involve multiple participants, evolve over time, require documented decisions, and cannot always follow a predetermined sequence.
Investigations, Compliance, and Incident Management
Internal investigations are a textbook ACM scenario. Whether the matter involves fraud, HR complaints, regulatory compliance, or information security incidents, each case arrives with only partial information and proceeds based on what is discovered. An investigator reviewing a suspicious expense pattern cannot know in advance whether the next step will be interviewing a witness, requesting financial records, involving legal counsel, or closing the matter. The path depends on what turns up.
What cannot vary is the audit trail. Every action taken, every document reviewed, every decision made needs to be recorded, timestamped, and attributable. The case worker needs flexibility in how to proceed and absolute accountability for what was done. ACM handles both requirements at once, because the case record captures all activity against the case without requiring that activity to follow a predetermined sequence. Auditability in ACM is structural, not procedural. You do not need to follow a script to produce a defensible audit. You need to work inside a system that records everything regardless of which path you took.
Customer Complaints, Service Requests, and Back-Office Knowledge Work
Complex customer complaints rarely follow the same path twice. A complaint that involves a billing dispute, a service failure, and a request for compensation touches three different teams, requires gathering documentation from multiple systems, and may need to involve a manager or legal review depending on the amount in question. Routing the case through a fixed workflow almost always produces gaps, because the workflow designer could not anticipate every combination of circumstances.
ACM handles this by treating routing as responsive rather than predetermined. The case intake creates the record, initial triage assigns it, and then the case worker and the business rules together determine the next steps as case data builds up. When a specialist needs to be brought in, they are added to the case. When a document needs to be requested, that task is attached. When the case resolution requires approval, that milestone triggers the relevant rule. The inbound and outbound communication stays in the case record rather than fragmenting across email threads.
The same logic applies to underwriting, insurance claims, and legal casework - forms of back-office knowledge work where the file is the work product and the work product changes shape throughout its lifecycle.
Healthcare Care Pathways and Government Citizen Services
Healthcare is where some of the strongest empirical evidence for ACM effectiveness sits. A 2023 randomized controlled trial published in the Journal of Medical Internet Research evaluated a practice-proven adaptive case management approach called Health Circuit, designed for implementing evidence-based integrated care pathways in complex, long-running healthcare cases. The study found that the approach was feasible and effective for empowering both professionals and patients in personalized, evidence-based interventions. The key operational feature: care plans were adaptive, with tasks, appointments, and monitoring activities adjusted based on patient data and feedback rather than locked into a fixed sequence. The health plan evolved with the patient's situation, professionals could update it asynchronously, and the system supported nurse case coordination across multiple stakeholders without requiring everyone to work from the same rigid protocol.
Government citizen services face similar structural demands. A citizen applying for social support, disability benefits, or housing assistance may need different documents, different assessments, and different interventions depending on their specific situation. The underlying policy framework is consistent. The path through it is not. ACM supports the caseworker who needs to follow policy while also adapting to the individual circumstances of each case - a combination that rigid workflow tools consistently fail to accommodate without either massive exception handling or a parallel informal process run by the caseworkers themselves.
Teams managing caseloads in these environments tend to discover the same thing eventually: the tool that was supposed to support their work becomes the obstacle to it, and the case managers spend more time working around the system than inside it.
For operations teams looking to integrate ACM with broader process automation, a practical option is connecting case intake, routing logic, and external notifications through a low-code platform like Latenode. In the healthcare operations scenario from Section E above, a Latenode workflow can listen to events from core case systems, route incoming documents (discharge summaries, referral letters, scanned forms) into a unified case record via built-in integrations with automatic OAuth, and apply JavaScript-based escalation logic that adapts as the case evolves - all without requiring a custom backend or a separate scraping service. The advantage here is that multi-step, multi-system workflows that pull from several tools and run AI summarization still count as a single execution, which keeps the cost predictable when case volumes are high and each case touches many external systems. That said, the OAuth access and a basic case ID convention need to be in place before the workflow can run. Setup is typically 60-90 minutes once those prerequisites are met.
![]()
How Adaptive Case Management Works - The Mechanics Behind a Live Case
Understanding that ACM is different from BPM is useful. Understanding how an ACM system actually runs is what lets an operations leader evaluate whether the tooling they are looking at actually delivers on the model.
The KMWorld analysis describes ACM as an umbrella approach that brings together workflow, content management, business rules, a participant portal, and collaboration tools across the full case lifecycle. That combination is not incidental. Each of those components plays a specific role in making a case run, and an ACM system that is missing any one of them will show the gap in production.
The Adaptive Process in Motion - Tasks, Events, and Ad Hoc Decisions
A live case in an ACM system starts with an intake event: a new request, complaint, incident, or referral creates the case record and assigns initial context. From there, the adaptive process runs through four main mechanics: tasks, events, rules, and ad hoc decisions.
Tasks are assigned to knowledge workers. They may be predefined for a case type, or they may be added as the case evolves. In a standard BPM system, adding a task that was not in the original model requires a process update. In ACM, adding an unstructured ad-hoc task is a standard feature of the interface. The case worker sees the current state of the case, decides what needs to happen, and creates the task directly on the case record.
Events drive rule-based actions. When a document arrives, a deadline passes, or a status changes, the rule engine evaluates whether any defined actions should trigger. The case evolves based on these events without requiring manual intervention for each one. A supervisor does not need to check daily whether an SLA is about to breach. The system checks, and when the threshold is crossed, the escalation fires.
The decision-making process in ACM is explicitly shared between the system and the worker. The system enforces compliance thresholds and triggers mandatory steps. The worker handles judgment calls that the rules cannot capture. Both contributions live in the case record, which means the case history shows what happened and why, regardless of which party drove each step.
What an ACM Process Platform Has to Handle Before You Should Trust It
I have looked at a fair number of platforms that claim ACM capabilities. The gap between the sales demo and production reality usually shows up in four areas.
Content management inside a single case. A case generates documents, emails, notes, and attachments throughout its lifecycle. If those artifacts live outside the case record in a separate content management system with a manual linking process, you have already split the case in two. A credible ACM process platform either includes content management or has a genuine integration that treats every document as a first-class case citizen, not an attached file reference.
A rule engine that case workers can understand. The compliance and escalation rules that govern cases need to be visible and adjustable by people who are not engineers. If changing a business rule requires a developer and a deployment cycle, the rules will fall behind the reality of the work within six months.
An audit trail that writes itself. Every action taken on a case should be logged automatically, with a timestamp, a user attribution, and enough context that a reviewer can reconstruct what happened without asking the worker to remember. Low-code ACM platforms that rely on manual documentation of decisions are not really ACM - they are workflow tools with a case-flavored UI.
Scalable collaboration without email bleed. Cases involve multiple participants who need to see, act on, and update the same record. If the collaboration mechanism is primarily email, with the case system used as a filing cabinet after the fact, the case record is always behind the actual state of the work. A real ACM platform makes the case the communication channel, not the inbox.
📊 In practice:
The Health Circuit RCT described in the Journal of Medical Internet Research evaluated ACM in exactly these terms: a shared, adaptive care plan all stakeholders could see and act on in real time, with asynchronous updates that did not require synchronous meetings. The operational design matched the theoretical requirements. That alignment between model and mechanics is what distinguishes a real ACM deployment from a workflow tool with a case-flavored skin.
The Misconceptions That Send Teams to the Wrong Tool
Three misconceptions show up consistently when teams are evaluating whether ACM applies to their situation. All three are expensive to learn the hard way.
ACM is just a more flexible BPM system
Teams that believe this use ACM software to model predefined workflows with slightly more complex branching logic. The operational failure looks like this: the tool has more configuration options than the old BPM platform, but the team still spends months modeling edge cases and still ends up with workers routing around the system whenever something unexpected happens. ACM is not a more configurable process engine. It is a different coordination model where the worker drives the path and the system supports that decision-making rather than constraining it. Business procedures still exist in ACM - they live in milestones and rules, not in sequence diagrams. Teams that do not make this distinction end up rebuilding the same rigid structure in a tool that was designed to avoid it.
ACM removes structure and relies on improvisation
This is the misconception that makes compliance-sensitive teams walk away from ACM before they have fully evaluated it. The assumption is that giving knowledge workers control over the path means there are no controls at all. In practice, ACM combines a flexible framework with enforced governance requirements. Business users cannot bypass a mandatory approval milestone because it is embedded in the case structure, not in a manually followed checklist. The audit trail is automatic. Deadlines still trigger escalations. The flexibility is in how the work gets done between the required milestones, not in whether the milestones exist. Conflating flexibility with improvisation is how teams end up choosing BPM for work that genuinely needed ACM, then wonder why their exception rate keeps climbing.
ACM is only relevant for legal and healthcare
This is the one that I find costs teams the most, because it causes them to stop evaluating before they have looked at their own situation clearly. The belief that ACM is a niche tool for specialist industries leads workflow teams in finance, HR, operations, and government services to automate their knowledge work with rigid tools, then build increasingly elaborate workarounds when the automation breaks on edge cases. The business case for evaluating ACM is not industry membership. It is the nature of the work: if your cases are unique enough that a fixed workflow produces exceptions more often than it handles cleanly, ACM deserves a serious look. The domain does not matter. The work pattern does. And I keep seeing this play out in teams that should have been in ACM conversations six months before they finally got there.
🤔 Think about this:
The teams that discover the BPM-to-ACM mismatch tend to discover it at the worst possible moment: when the first real set of edge cases arrives in production and the workflow tool cannot accommodate them. By then, the rigid automation is already embedded in the stack, the workarounds are already running in parallel, and the cost of switching is much higher than the cost of choosing correctly at the start. The question worth asking before you buy: what percentage of cases in your domain follow the same path end to end? If the honest answer is less than half, you are probably looking at the wrong tool category.
When to Choose Adaptive Case Management Over Standard Workflow Automation
The decision is not about sophistication. It is about the nature of the work.
Choose adaptive case management when: the path through a unit of work cannot be defined before it starts; when knowledge workers need to apply judgment at multiple points and the right next step depends on what was discovered, not on what was planned; when each instance is different enough that maintaining a comprehensive process model would cost more than the process saves; when compliance and auditability matter but the specific steps that satisfy them vary by case; and when the work involves multiple participants whose coordination cannot be fully orchestrated in advance.
According to ArkCase's documentation of the ACM model, the targeting criterion is direct: ACM is built for frequently changing or completely unpredictable processes where the organization needs to learn from outcomes, not just execute a defined sequence. If your process changes quarter to quarter because the work changes, standard workflow automation will require constant re-modeling. ACM absorbs that change as a feature, not a problem.
Do not choose ACM when: the process is genuinely repeatable, the path is the same for every instance, and the main goal is throughput and consistency. Invoice processing. Standard onboarding checklists. Scheduled data synchronization. These are jobs for structured workflow automation, and adding ACM overhead to them adds complexity without adding value.
A practical decision frame:
| Signal | Direction |
|---|---|
| Most cases follow the same path end to end | Standard workflow automation |
| Exceptions are more common than rule-following instances | ACM |
| Workers regularly route around the tool | ACM |
| Audit trail matters but the path to compliance varies | ACM |
| Process re-modeling is constant just to keep up with reality | ACM |
| Multiple specialists join and leave the case as it evolves | ACM |
When evaluating adaptive case management software specifically, the three things worth checking before anything else: whether ad hoc task changes are a first-class feature or a workaround, whether the audit trail is automatic or requires manual documentation, and whether business rules can be updated by case managers without a developer in the loop. Software vendors in this space, from Papyrus Software (ISIS Papyrus, Papyrus ACM, Papyrus Platform) to purpose-built open-source options, vary significantly on all three. The Papyrus ACM approach is one of the more cited examples in older literature on this topic, though the landscape has expanded considerably. The criteria matter more than any particular vendor's positioning.
![]()
References
- DataHorizzon Research - Adaptive Case Management (Acm) Market Size, Growth, Share & Forecast 2033 - 20/01/2025
- DataInsightsMarket - Exploring Innovation in Dynamic Case Management Industry - 03/07/2024
- Journal of Medical Internet Research - A Practice-Proven Adaptive Case Management Approach for the Implementation of Evidence-Based Integrated Care Pathways in Health Care - 13/06/2023
- CMSA Today - The Evolution of Hospital Case Management: Moving Beyond the Triad Model - 08/06/2025
- i-SCOOP - Case management: the changing case for advanced, dynamic and adaptive case management - 30/07/2017


