When does Flowable CMMN case management fit better than a process?
Flowable CMMN cases suit work driven by conditions and human judgment, while BPMN suits fixed flows where the sequence of steps is known before the work starts. Knowledge-intensive work such as claims handling, investigations and onboarding exceptions often fits the first pattern, because the next step depends on what a handler finds. A useful test is whether a competent handler could list the steps for a typical case in advance. If yes, and exceptions are few, a process is usually easier to build, test and audit. If no, and the work is better described as goals, stages and conditions that become active in different orders, case management is the stronger match.
Flowable's open source engines, licensed under Apache 2.0 and exposed through Java and REST APIs, include CMMN alongside BPMN and DMN, so the engine itself is rarely the constraint. The harder work is modeling and governing human decisions: which stages exist, which tasks are discretionary, what a milestone means to the business, and who may close a stage early. These decisions belong to case owners and domain experts, and they determine whether the model holds up in production. Before committing, run a workshop with two or three case handlers and record which situations they handle differently and why. Those recorded variations become the first test cases for the model.
Three things make CMMN harder than it looks. First, sentries can fire on the wrong events. A sentry that combines a condition with an event may trigger on a document upload that was only a correction to earlier work, so each sentry needs a clear definition of the events that count. Second, case state can drift from business reality when users mark stages complete without doing the underlying work, or when status changes happen outside the case. Reconciliation against the system of record needs an owner. Third, BPMN and CMMN models often end up with separate owners. When a case calls a process for a fixed sub-step, a change in one model can break assumptions in the other, so agree on model ownership, version rules and the interface between them before build starts.
Plan verification around these three risks from the start. In a proof of concept, test each sentry with both matching and non-matching event sequences, confirm that milestones reflect outcomes rather than activity, and check that the audit history records who changed case state and when. Confirm with Flowable and in your own environment which case history and query capabilities your target version provides, and check the documentation for that exact release. Also decide early whether the CMMN engine will run embedded in your Java application or be reached through the REST application, because that choice determines where case state, history and access controls live.
Which CMMN elements and engine parts you will model and configure
A CMMN case is built from a small set of model elements, and each one runs on engine parts that your team must install, configure and keep running. The cards below cover the modeling vocabulary first, then the runtime pieces that store and execute case instances, and the version alignment that decides whether the stack starts at all.
Case plan model and case plan items
The case plan model is the top-level CMMN definition that holds every stage, task, milestone and sentry for one kind of case. Case plan items are the individual elements placed inside it, and each one carries its own lifecycle that the engine tracks at runtime. Before modeling, confirm with the Flowable CMMN documentation for your version which plan item types and attributes it supports, since element coverage differs between releases.
Stages and nested case structure
Stages group related plan items into a unit of work that can be opened, completed or terminated as a whole. They are where you decide how a case is divided, for example intake, assessment and decision in a claims case. Nesting stages makes the model easier to read but also makes runtime state harder to inspect, so agree the depth with the operations team before the model is finalized.
Human tasks and task assignment
Human tasks are plan items that wait for a person to act, and they create work items that your task UI or API must surface. Decide early how candidate users and groups are resolved, because the engine only stores the assignment and your identity source supplies the groups. Check which human task attributes your target version supports, including due dates and form references, before designing the user experience.
Milestones and sentries
Milestones record that a business condition has been reached, and sentries are the entry and exit criteria that decide when a stage or task becomes available or is closed. Sentries that reference case file items or events are the most common source of unexpected behavior in testing, so each one needs a written condition and a test case. Confirm the supported sentry condition types for your version in the vendor documentation.
CMMN engine and REST application or embedded engine
The CMMN engine executes case instances and can run embedded in your Java application or as the Flowable REST application over HTTP. The choice sets how you deploy, scale and secure case execution, and it affects who calls the engine. Decide this with the architecture team, since it determines whether the REST API needs its own authentication and network controls.
Database schema and Spring Boot CMMN starter
The database schema stores case definitions, case instances, plan item state and history, and the Flowable configuration docs list supported database types such as PostgreSQL, MySQL, Oracle and Microsoft SQL Server. The Spring Boot CMMN starter wires the engine into a Spring Boot application, and the Flowable Spring Boot docs describe starters for the CMMN engine. Flowable 8.0.0 moved to Spring Boot 4 with no backward compatibility for Spring Boot 3, so confirm that your starter version matches your Spring Boot line before building.
Case or process: which model fits each piece of work
This table compares the four common ways to combine Flowable BPMN, CMMN and DMN for a piece of work, with the fit, operational cost and model ownership of each. Read each row as a question: is the path known in advance, does a person decide what happens next, and where should the decision rules live. The main takeaway is that most teams need a mix of models, and the ownership and testing burden grows with each model type added.
| Model option | When it fits | Operational cost | Who owns the model |
|---|---|---|---|
| Pure BPMN process | The steps and their order are known in advance and mostly automated, with few points where a person chooses the next step. | Lowest. Monitoring focuses on running instances and failed jobs, and testing follows a fixed set of paths. | Process analysts or engineers who own the flow, with the business owner signing off on the steps. |
| CMMN case with human tasks | The work is knowledge-intensive, the order of activities depends on what is found, and workers decide which tasks to start, skip or repeat. | Higher. Sentries, stages and milestones need scenario testing, and audit must show why a task was or was not offered. | Case designers working with the operations or domain team, since the case reflects how experts actually work. |
| CMMN case that calls BPMN subprocesses | A case manages the overall work, while some stages run a fixed, repeatable sequence that should be modeled as a process. | Higher than either model alone, since two model types must be versioned and tested together, including the call contract between them. | Split ownership: the case owner controls stages and sentries, and each subprocess owner controls its own flow and its inputs and outputs. |
| BPMN process that calls a DMN decision table or CMMN case | A process step needs a rule-based decision, such as a routing or eligibility rule, or a bounded piece of case work that a process should hand off. | Moderate. Decision tables need their own test cases and version history, and the calling process must handle the decision's outputs correctly. | The decision table is owned by the team accountable for the rule, and the process owner keeps the calling step and its error handling. |
How to build a Flowable CMMN case in sequence
This sequence takes a case-driven business process from a scoped case type to a deployed, tested CMMN model that starts and moves through its states as the business expects. Each step closes with a check the business owner and engineering team can both sign off before the next step begins.
Scope one case type and its outcome
Start by choosing a single case type, such as a claim, an onboarding file or an incident, and writing down the business outcome it must reach and the roles that touch it. The business owner and a solution architect agree on who opens the case, who decides what happens next and who closes it. The step is done when the outcome statement and role list are signed by the business owner, and the team can say in one sentence why this work suits case management rather than a fixed process.
List stages, milestones and their owners
Break the case into stages that group related work and milestones that mark progress the business cares about, such as documents verified or risk assessed. Assign each stage and milestone a business owner who can confirm when it has been reached. Walk through two or three real examples from past files to check that the stages cover them without gaps. The check is a stage and milestone list reviewed with the business owner, where every milestone has a named owner and no file in the sample falls outside the model.
Define sentries and their triggering events
For each stage or task that should only activate under a condition, define a sentry: the event or set of events, and the condition that must hold, that makes it available. Keep the triggers concrete, such as a document uploaded, a case field changing or a timer firing. Separate the events that happen inside the case from those that arrive from outside, because they are wired differently later. The check is a table of sentries, each with its triggering event, its condition and the owner who agreed it, reviewed against the stage list from the previous step.
Assign human, service and process work
Decide, for each planned task, whether a person performs it (human task), an application call performs it (service task), or a separate BPMN process carries out a longer, fully sequenced piece of work (delegated process). Note which decisions should come from DMN tables rather than code or person judgment. Record the assignee groups for human tasks, since identity mapping is a separate integration. The check is a task-type register reviewed by the architect and a business owner, with every task assigned to exactly one type and no task left without a named owner group.
Model the case and deploy it
Draw the case in the CMMN modeler using the stages, milestones, sentries and task types agreed above, and keep the element names aligned with the business vocabulary. Deploy the model either through the engine's deployment API or, in a Spring Boot application, by placing the case file in the location the Flowable Spring Boot starter auto-deploys from. Confirm the deployment version in the engine's repository before testing. The check is a diagram review sign-off from the business owner and a successful deployment that the engineering team can find in the engine by case definition key.
Wire service calls and DMN decisions
Connect each service task to its Java implementation, using the delegate or expression approach your team has chosen, and bind each decision point to its DMN decision table with the agreed input and output fields. Check that variables passed into service tasks and returned from decisions match the names in the model, since mismatches are a common source of silent failures. Keep failure handling explicit for each call. The check is a unit test per service task and per decision table that passes with representative inputs, plus a reviewed list of variable names.
Start a case through the API
Start a case instance using the Java case service or the REST API, passing the business key and initial case variables that the model expects. Start with one case of each main path, for example a standard file and an exception file, and confirm that the instance is created with the expected case definition version. Record how your application will supply the business key so support staff can find the case later. The check is a started case instance visible through both the Java call and the REST call, with the business key and variables matching the input.
Test the state transitions
Write automated tests that drive a case through its main states and exception states, asserting that stages activate, sentries open and close as designed, milestones are reached only when their conditions hold, and the case completes or terminates correctly. Include at least one test where a sentry should not fire, because those are easy to miss. Share the test results with the business owner, who confirms that the transitions match the business rules. The check is a passing suite of state-transition tests, reviewed against the outcome statement written in the first step.
How to test that case plans, sentries and milestones behave correctly
A CMMN case is only ready for go-live when its sentries, stage completion rules and milestones behave as the business expects under the event sequences that real work produces. Test each sentry in both directions. A positive test sends the event or condition combination that should trigger it and confirms the plan item becomes available or the milestone is reached. A negative test sends the near-miss sequences, such as the sentry's trigger arriving before its condition is true, the condition becoming true without the event, or the event repeating after the item has already been completed. Many defects in case models hide in the negative cases, because the engine does what the model says, and the model did not say what the business intended. Next, confirm that a stage does not complete while mandatory items remain open. Build a scenario where one required human task is left unfinished and every other item is finished, then check that the stage stays active. Repeat the check with the mandatory item completed, terminated, or skipped through its own rules, since each path can leave the stage in a different state. Then verify milestones: a milestone should be achieved only when its entry criteria are satisfied, and it should be reactivated correctly if the case re-enters the state that required it. Assert the case state and the milestone state directly through the Flowable CMMN runtime and history services, not only through the user interface, so a regression shows up as a failed assertion. Test failure behavior as deliberately as success behavior. Create cases with missing input data, a decision that returns no result, and a service task whose call fails, then confirm that the case stops in a state that an operator can find and act on. Check that the failure appears in the list of active or waiting cases, that the reason is recorded in history, and that a retry or manual continuation is possible. Decide in advance which failures are retried automatically and which are routed to a person. Running these tests against a database schema that matches production is important. The Flowable configuration docs list H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types, and H2 is convenient for fast unit tests but can hide dialect differences. If you run MySQL, confirm your exact server version: versions below 5.6.4 lack millisecond precision, which can reorder events that occur within the same second and make timestamp-based assertions flaky. Use a pinned, production-matching engine version for integration tests. Finally, keep a set of named case scenarios as regression tests and run them on every model change, engine upgrade and database change. Each scenario should document its starting data, the event sequence, the expected stage and milestone states, and the expected failure handling. Keep the set small enough that the team runs it on every merge, and extend it whenever an operator reports a defect. Ask your implementation partner to deliver this suite as part of the fixed-scope work and to explain how it will be maintained after go-live, since the suite is what protects the case model during later Flowable upgrades.
How CMMN cases run on a single node versus several nodes
In a single node setup, the CMMN engine is embedded in one application, either a Spring Boot application or a servlet application running in a container such as Tomcat or Jetty. That one process owns the engine, the job executor threads and the database connection pool, so case instances, timers and asynchronous jobs all run inside it.
- Scheduling stays local. The executor in the same process picks up timers and async jobs, so there is no coordination between nodes to reason about.
- Fewer failure modes. One set of logs, one restart procedure and one place to look when a sentry does not fire.
- Limited availability. If the process stops, case progression pauses until it restarts. Confirm the recovery time your business needs before choosing this model.
- Vertical scaling only. Capacity grows by changing the host and executor thread pool settings, which limits headroom under peak load.
- Common starting point. Teams often begin here to validate case models before they add nodes.
Check how the executor thread pool size and database connection limits are set, and confirm how in-flight timers behave after a restart in your Flowable version.
With several nodes, each application instance runs the engine but keeps no case state in memory. Case instances, tasks, timers and jobs live in a shared database. Each node's async executor coordinates through lock owners and lock expiration times stored in that database. A node claims a job by writing its owner identifier and an expiry time. If the node fails before finishing, the lock expires and another node claims the work.
- Stateless instances. Any node can serve a REST or Java call, so a load balancer can route requests freely.
- Lock-based claiming. The lock owner and expiry time in the database decide which node runs a given timer or async job.
- Expired lock recovery. Work from a failed node is reclaimed once its lock expires, so the expiry setting controls how quickly recovery happens.
- Database as the shared dependency. The database becomes the main availability and performance boundary, so its high availability design matters as much as the engine.
- Same model for CMMN timers. Case timers and asynchronous jobs follow the same locking model. Confirm the exact CMMN timer behavior in your version before relying on it for deadlines.
Test a node stop during an open timer and confirm that the timer fires once on another node after the lock expires.
The Flowable REST application exposes the engines over HTTP, so several client systems can start cases, query case instances and complete human tasks through one central case API. The engine runs as its own service, and client systems do not embed Flowable. This model suits organizations where several applications need the same case records, but it moves security and capacity decisions onto a single endpoint.
- One place for case access. Client systems share one set of case definitions and instances.
- Securing the endpoint. Authentication, authorization for each case and task operation, and transport encryption must be designed for every caller. Plan the OAuth2 or OpenID Connect integration early.
- Scaling the service. The REST tier can run as several instances against the same database, which adds load balancing and session planning.
- Coupling and versioning. Every client depends on the API contract, so changes to case models and endpoints need a coordinated release plan.
- Operational ownership. One team usually owns uptime, patching and monitoring of the endpoint, which affects on-call duties.
Ask for a written list of the endpoints each client will call and the identity model they use, then confirm which Flowable REST operations your version exposes.
What drives effort in a Flowable CMMN case project
This table lists the factors that change the size of a Flowable CMMN case project and a practical way to keep each one contained. Read it as a checklist to raise with a partner before scope is agreed, because the effort is set by the written scope rather than by any general estimate. The main takeaway is that most effort grows with the number of case types, external events and integrations, so fixing those early has the largest effect.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Case types and stages | Each case type needs its own stage plan, plan items, milestones and scenario tests, so effort grows with every added case model. | Start with the cases that have the most variation. Reuse stages and plan fragments across case types where the work is the same. |
| Sentries and external events | Entry, exit and reactivation criteria mix timers, human events and data conditions, and each condition must be tested both on and off. | Reuse a small set of named sentry patterns. Agree which events come from which system before modeling begins. |
| Integrations with existing systems | Each service task, inbound event or callback needs an API contract, error handling, retries and test doubles. | List every system the case reads or writes. Confirm the owning team and the interface version for each before work starts. |
| Human task roles and identity mapping | Candidate groups and assignees must match identities in the client directory, which often differs from the names used in the model. | Agree the role-to-group mapping with the identity owner early, in writing. Keep the role list short and stable. |
| DMN decisions and BPMN subprocesses | Decision tables and called processes each add their own inputs, outputs, versions and tests, and they must agree with the case data model. | Use DMN only where rules change often or need business review. Define input and output contracts once and version them. |
| Environments and database choice | Each environment needs its own schema, deployment pipeline and configuration, and the supported database type affects setup and testing. | Confirm the database engine from the supported list in the Flowable configuration docs before scoping. Limit the number of environments that receive case deployments. |
| Compliance evidence needs | Assessors may ask for records of who changed a case model, which tests ran and how human decisions were logged, which adds work to design and test. | Define the evidence list up front, such as version history, test results and audit history. Build the evidence collection into the sprint process rather than adding it at the end. |
| Team skills | Teams new to CMMN concepts such as sentries, planning tables and discretionary items need more modeling review and pairing. | Confirm which skills the client team already has. Schedule modeling review sessions and agree who signs off on each case model. |
How to control who can act on case tasks and see case data
Access control in a CMMN case is decided at three points: who may start a case, who may see and act on its human tasks, and who may trigger the operations that change a case's state, such as reopening a stage or reactivating a milestone. Write these down as a table of actions by role before modeling begins. CMMN describes what a case can do but does not decide which person may trigger a transition, so that decision sits with your design and must be enforced at the engine's API layer. Human tasks usually reach people through candidate users or candidate groups, so the group names in your directory need to be settled first. Confirm with the Flowable security documentation for your version how case start and task claim checks are applied, since a model alone does not stop an unauthorized caller.
Identity sits underneath every one of those checks. Flowable allows identity management to be replaced by implementing the IdmIdentityService interface or by overriding IdmIdentityServiceImpl, and it provides an LDAP identity service as a reference implementation. Decide before modeling whether the directory is the source of truth for users and groups, which directory groups become the candidate groups in each human task, and how the engine learns that a person has left a group. If a user is removed from a group, open tasks may still show that person as a candidate until the mapping is refreshed, so test that path explicitly. Ask your directory team how the reference LDAP service handles nested groups and caching in your environment, and confirm the behavior in the version you deploy.
The REST API is the second entry point. When the REST application or a Spring Boot REST starter is used, every case operation over HTTP needs authentication and authorization in front of it. Map each endpoint to the roles allowed to call it, and keep operator actions such as reopening stages or reactivating milestones on separate endpoints or service accounts, apart from end-user task actions. Do not assume that the engine enforces task ownership on every path. Test each denied call with a user who lacks the right role. Confirm with the Flowable security documentation which endpoints need explicit protection in your version, how Spring Security is wired into the REST layer, and whether any default accounts ship enabled that must be removed before go-live.
Sentries and case item conditions are expressions the engine evaluates at runtime, so anyone who can change a case model can change what runs inside the engine. Restrict who may author, deploy or edit case models, and review every expression change as code. Prefer expressions that read case variables and call approved Java beans over open-ended scripting. Confirm which expression and script languages your version enables by default and how to switch the others off. Keep database credentials in externalized configuration such as environment variables or a secrets manager, and out of case model XML, deployment resources and case variables that are written into history. Verify this by searching deployed artifacts and case history for connection strings before go-live.
Case history is part of your audit trail. It records what happened to the case, including stage transitions, task completions and variable changes, so the history level and retention period are compliance decisions that you own. Set the retention period according to your organization's own policy, and document it. Confirm in the Flowable configuration documentation which history level captures the CMMN events you need. Make sure any cleanup or purge job respects that retention, and that history tables are included in your backup and restore plan. Also decide who may read history, because case history can expose data that the current user is no longer allowed to see on the live case.
What to monitor, back up, upgrade and document after go-live
A case model that works in testing still needs watching once real cases arrive. The four areas below connect because each depends on the same database tables, the same deployed case versions and the same people who will handle cases that stop moving.
Monitor running cases and jobs
The Spring Boot starter exposes an actuator endpoint at /actuator/flowable that reports on running processes, which you can expose to your monitoring stack. Alert on cases that sit in one stage longer than your expected handling time, on failed asynchronous jobs, and on timer or job locks that stay held past their expiry. Confirm which metrics your Flowable version exposes and how your platform scrapes them before go-live, because these signals are the first sign of a stuck case.
Back up case and history tables
Database backups must include the case instance, plan item, task and history tables, not only the process tables your team thinks of as primary. A restore that brings back case definitions without the matching runtime state leaves open cases orphaned. Schedule restore tests against a separate environment and record how long a restore takes and which checks confirm the cases resume correctly. Ask your database team to confirm point-in-time recovery covers the same schema.
Plan upgrades from 7.x to 8.0
Flowable 8.0.0, released February 27, 2026, moves to Spring Framework 7 and Spring Boot 4, and its release notes state there is no backward compatibility for Spring Boot 3. Jackson 3 becomes the default JSON library, with a Jackson 2 compatibility layer, and JUnit 3 and 4 support is removed. Plan for case models and regression tests to be rerun on the new stack. Also confirm how the version you run handles changes to a deployed case model for cases already in flight.
Document case models and runbooks
Keep a record for each case model version that states which cases it covers, the rationale for each sentry, and the role mapping that assigns human tasks to groups. Include an operator runbook that explains how to identify a stuck case, what checks to run, who may move a case forward or terminate it, and when to escalate. Store these documents alongside the model files, so the reasons behind a sentry remain available to auditors and to the next team that changes the model.
How much effort does Flowable CMMN case management take, and what do we need to provide?
What drives the cost and effort of a Flowable case build?
Scope agreed in writing is the main driver. The effort depends on the number of case types, the stages, sentries, human tasks and milestones in each case, the integrations that send or receive case data, the roles that act on tasks, and the number of environments you need. A case with a few stages and one approval role is a much smaller job than a set of cases that combine BPMN processes and DMN decisions and call several internal systems. The Flowable engines are licensed under Apache 2.0, so the engine itself carries no license fee. Your costs are the labor to model, build, test and run the solution, plus the infrastructure beneath it. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for each driver above to be priced separately.
How long does a Flowable CMMN case project usually take?
The timeline is set by the written scope, and no fixed duration applies to every project. The main variables are how many case types are in scope, how many stages and sentries each one needs, how many systems the cases must read from or write to, and how quickly business owners can confirm their conditions. Modeling is often quicker than agreeing what a sentry means in business terms, so decision speed frequently sets the pace. Ask for a plan that names each milestone, the owner who signs off each stage and sentry, the environments used for testing, and whether model review happens before build starts. Your own team's available time also affects the schedule, so confirm that capacity at the outset. Fixed-scope engagements have their deliverables and timelines agreed before work begins.
What must our team provide before a Flowable case build starts?
Four inputs carry most of the load. First, named business owners who can decide the conditions behind each stage and sentry, and who can approve milestones. Second, role and identity data, including the groups or roles that should receive human tasks and where that data lives. Third, a database and hosting target that meets your standards, plus the network and access controls that go with it. Fourth, test data that reflects real case types, including edge cases such as incomplete information, reopened cases and escalations. Without these inputs, models stall in review because nobody can confirm the business logic. Ask the implementation partner to list each input in the written scope, with the person responsible for providing it and the date it is needed.
Can an internal team build Flowable CMMN case management alone?
Yes, if the team has Java, Spring and case modeling skills and time to own the models after go-live. Flowable can be embedded as a JAR in Java SE applications, servlet containers, Spring applications or Java EE servers, or run as the REST application over HTTP. The Spring Boot documentation describes starters for the CMMN engine, which shortens setup. The harder part is usually the modeling discipline: writing sentries that match business rules, versioning models, and testing changes against case instances that are already running. The team must also handle monitoring, database operations and upgrades, including the move to Flowable 8.0.0 if it targets Spring Boot 4. Ask whether the people who build the models will also maintain them after launch.
What does a partner add to a Flowable CMMN project?
A partner adds structure around the parts that most often slip. DeployOpen's work on a Flowable project can cover scoping, which decides which parts of the process should be modeled as cases, processes or decisions. It also covers model review against the business conditions agreed with your owners, testing of the cases and integrations, and handover so that your team can run and change the models without help. Because DeployOpen works on fixed-scope engagements, the scope, deliverables and timelines are agreed in writing before work starts. Ask any partner to show which of these activities are included, who performs them, and what documentation you receive at the end.
Which databases work with Flowable case management in production?
Flowable's configuration documentation lists H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server as supported database types. Choose the database according to your operating standards, licensing and the skills your operations team already has. If you use MySQL, note that versions below 5.6.4 lack millisecond precision, which matters for timers and case timing. For multi-node deployments, the async executor coordinates nodes through lock owners and lock expiration times stored in the database, so the database must be reachable and sized for that load. Confirm the exact versions you plan to run against the current Flowable documentation and your database vendor's support matrix before the design is frozen.
How do identity and role data reach Flowable human tasks?
Flowable manages identity through its IDM engine, which you can replace. The documentation says identity management can be replaced by overriding IdmIdentityServiceImpl or by implementing the IdmIdentityService interface, and an LDAP identity service is provided as a reference implementation. In practice, your team needs to decide where users and groups come from, how groups map to candidate users and candidate groups on each human task, and how changes in your directory affect tasks already in progress. Confirm which system is the source of truth for roles, how often it changes, and who approves a mapping change. Those answers determine how much custom identity code the project needs.
How DeployOpen scopes, builds and hands over Flowable case work
DeployOpen treats a Flowable CMMN case as a written, fixed-scope deliverable: the case model, its stages, sentries, human tasks and milestones, and the BPMN and DMN parts it depends on are agreed before build starts. The work runs inside your own infrastructure, and your team receives the models, code, tests and documentation needed to run the cases after go-live.
How we scope
- Agree which case-driven work becomes a CMMN case and which steps stay BPMN processes or DMN decisions.
- Document each case's stages, sentries, milestones and human tasks, with the roles that can act on each task.
- Confirm the Flowable engines in use, the target database, and whether the engine runs embedded in Spring Boot or through the REST app.
How we build
- Model cases in the Flowable CMMN engine, wiring sentries to events, data changes and timers, then link them to BPMN subprocesses and DMN tables.
- Connect cases to your systems through Java delegates or service tasks, with identity mapped to your directory and candidate groups.
- Test cases against written scenarios, including unexpected orderings, reopened stages and tasks left open for long periods.
How we hand over
- Deliver case and process models as versioned files, with the source code, configuration and deployment steps your team needs.
- Provide documentation that explains each case's lifecycle, sentry conditions, roles and how to add a new case or stage.
- Walk your engineers through running, monitoring and changing the cases, and record open questions in the handover pack.
How we support
- Agree the support boundary in the written scope, covering fixes, questions and changes after go-live.
- Offer ongoing support, upgrades and regression testing of case models as a retainer when your team wants continued help.
- Plan Flowable version upgrades, including database schema changes, and retest case models before each upgrade reaches production.
