Why insurers use Flowable for claims and underwriting
Claims and underwriting leaders carry work that passes through adjusters, underwriters, complaint handlers and, eventually, regulators, and each group needs to see the same rules and the same record. Flowable's CMMN, DMN and BPMN engines fit this work when the handling logic and the evidence behind each decision must be explicit rather than buried in individual desktop practice. Flowable runs open-source engines under the Apache 2.0 license, so the case models, decision tables and process definitions can live in your own repositories and infrastructure, with Java and REST APIs for the systems around them.
The practical change is in three places. Claim handling becomes a case: CMMN stages, sentries and milestones describe what must be true before a claim can move on, while a human task inside the case stays open for an adjuster's judgment. Underwriting and routing rules move into DMN decision tables that a reviewer can read and test against sample risks, and a process or case calls them by name instead of duplicating the logic. Because the engines record history, the path a file took through its stages and decisions can be reconstructed later for a complaint or an examination. Confirm with your compliance team which history fields and retention periods your regulators expect before you design the audit view.
Adoption also depends on where the engines run. Flowable can be embedded as a JAR in Java SE applications, servlet containers such as Tomcat or Jetty, Spring applications or Java EE servers, or used over HTTP through the Flowable REST application. Choose the pattern that matches how your core policy and claims systems are already deployed, and confirm the supported database types and the identity integration with your claims platform before the design is fixed.
Which insurance requirements shape the Flowable build
This table maps each insurance requirement to the source that drives it and the consequence for the Flowable build. Read it as a list of design questions to settle before modeling starts, not as a statement of which rules bind your company. Applicability depends on your jurisdiction, licence type and contracts, so confirm it with counsel and your compliance team.
| Requirement | Source to check | What it means for the build |
|---|---|---|
| Claims timeliness and fair handling | Your claims handling standards and local regulator rules (confirm with counsel) | Model claim stages as CMMN case plan items with SLA timers, and record every timer firing and escalation as history the case team can export. |
| Underwriting consistency | Your underwriting guidelines and model governance policy | Keep rating and eligibility logic in versioned DMN decision tables, call them from the underwriting process, and store the decision version with each file. |
| Complaint traceability | Your complaints procedure and regulator reporting expectations | Keep the case and process history, task assignments and decision versions linked to the policy and claim IDs so a complaint file can be reconstructed. |
| Outsourcing and ICT contract controls (DORA, EU insurers) | DORA Article 28(3), Article 28(8) and Article 30(2) | Record Flowable and any hosting or integration provider in your ICT register, state processing locations in contracts, and document an exit and data return plan. |
| Data location | GDPR, Regulation (EU) 2016/679, and your data transfer assessment | Deploy the engines, database and history store in infrastructure you control, and keep claimant data in process variables within the approved region. |
| Access control and security of operations | NIS2, Directive (EU) 2022/2555, where it applies to your entity | Integrate adjuster and approver identity through your own identity provider, restrict task and case access in the application, and log administrative changes to models. |
How claims and underwriting differ as Flowable applications
Claims rarely follow one fixed path. A first notice of loss may lead to coverage checks, third-party inquiries, repairs, reserve changes or litigation, and the order of those steps depends on what the adjuster learns. Flowable's CMMN engine fits this shape because a case model describes stages, plan items and sentries that become available when their conditions are met, rather than a single sequence of tasks. Human tasks give adjusters a work queue, while milestones and event listeners record when key points were reached.
- Stages and plan items: Model the claim lifecycle as stages whose tasks can be activated, skipped or repeated based on case data.
- Sentries: Express conditions such as a completed coverage review or a reserve threshold that open or close a set of tasks.
- Human tasks for adjusters: Assign work to roles or groups in your identity model, with ownership decided by your application.
- SLA timers: Use timer-based events or boundary behavior to escalate overdue items, then confirm in the CMMN docs how timers behave on case plan items.
- Case and process calls: Hand a settlement or payment step to a BPMN process when the work becomes sequential.
Confirm the exact CMMN element support, timer semantics and task assignment options in the Flowable documentation before you commit the claim model to a design review.
Underwriting and routing usually have a clearer order: intake, data checks, a risk or eligibility decision, then acceptance, referral or decline. A BPMN process gives that order an explicit, versioned model that operations and compliance teams can read. Decision logic such as eligibility rules, referral thresholds or triage routing belongs in DMN decision tables, which the process calls by key so that rule changes do not require a process redesign.
- Process flow: Model intake, validation, decision, referral and notification steps as BPMN tasks, gateways and events.
- Decision tables: Keep referral and eligibility rules in DMN, using the hit policy that matches how your underwriting guide reads the rules.
- Service and user tasks: Call external data providers or underwriting engines through service tasks, and route referrals to underwriters through user tasks.
- Versioning: Deploy new process and decision versions side by side, then decide which open instances move to them.
- Decision history: Enable decision audit records where your evidence requirements call for them, and confirm the history settings in the docs.
Check how your underwriting rules map to the hit policies and input expressions supported by the DMN engine before you write the decision tables.
A claim often starts as underwriting or routing work and later returns to case handling. The practical question is which engine owns each piece of state and how control moves between them. In Flowable, a BPMN process can call a DMN decision, and a CMMN case can start or call a process, so the handoff is a design choice rather than a fixed rule. Keep the case identity, business keys and key variables explicit so that an adjuster, an auditor and a support engineer can trace one claim across both models.
- Decision calls: A process task evaluates a decision and stores the output in process variables that drive the next gateway.
- Case-to-process calls: A plan item can start a process for a sequential step such as payment approval.
- Shared identifiers: Use a business key or a claim identifier variable so records can be correlated across instances.
- Variable scope: Decide which variables are copied across the handoff and which stay local, to limit data exposure.
- Failure paths: Define what happens when a decision or called process fails, including retries and manual recovery.
Confirm the exact call mechanics, variable mapping and correlation options in the Flowable CMMN and BPMN documentation before you finalize the handoff design.
Not every insurance workflow needs both engines. A simple, fixed-order intake may fit a single BPMN process, while a complex claim with many optional paths may fit a CMMN case with a few process calls. The choice affects how testers write scenarios, how operations diagnose stuck work and how compliance teams read the evidence. Make the decision per workflow, and record the reasoning so the team can revisit it when products or regulations change.
- Workflow shape: Favor BPMN when the sequence is stable and CMMN when the path depends heavily on case facts.
- Rule ownership: Favor DMN when business users change rules often and need to read the logic.
- Testing effort: Plan scenario tests for each path through a case and for each decision table row.
- Operations: Assess how support staff will find and recover failed jobs, timers and stuck case plan items.
- Evidence: Decide early which history and audit records you will present to complaint handlers and regulators.
When you ask a partner for a quote, ask them to show the engine split for each workflow and the reasons for it, and confirm the design against the Flowable docs.
Which Flowable modules and settings matter for insurance
Six Flowable components carry most of an insurance claims and underwriting build. Each one maps to a decision your claims, underwriting and compliance teams must make before the first process definition is deployed. Review them together, because a case model, a decision table and an identity service only behave correctly when the timers, monitoring and audit settings around them are also in place.
CMMN claim cases and sentries
Claims rarely follow one fixed path, so CMMN fits better than a rigid sequence for the work around a claim. Stages model intake, investigation and settlement, while sentries decide when a stage can open or close, for example when a damage assessment arrives. Map each sentry to a claims rule your claims committee can name. Check how a case reopens after a complaint, and confirm which plan items can be skipped without leaving an audit gap.
DMN underwriting tables
Underwriting rules belong in DMN decision tables so that underwriters and actuaries can review the logic without reading Java. Choose hit policies deliberately, because the policy decides whether one rule or several rules can match the same risk. Version each table with the product filing it supports. Ask your compliance team which rule outcomes must be explainable to a policyholder, and keep the input values that produced each decision in history.
BPMN routing and human tasks
BPMN handles the deterministic routing around a claim or application: which queue receives a task, when a referral to a senior adjuster is required, and when a payment request waits for approval. Human tasks should be assigned through candidate groups that come from your identity system, not from hard-coded user names. Decide which routing thresholds are configuration and which need a new deployment, since that choice controls how fast business teams can change them under regulatory pressure.
Async executor for SLA timers
Complaint response windows and claim service levels depend on timers that must fire even when a node restarts. The async executor runs timers from a thread pool and coordinates nodes through lock owners and lock expiration times stored in the database, so another node picks up expired work. Confirm the lock expiration interval against your escalation deadlines, and test what happens when the database is failed over during a timer window.
Identity service for adjuster roles
Adjusters, underwriters, supervisors and complaint handlers need different access to the same cases. Flowable lets you replace the identity management service by implementing the IdmIdentityService interface, with an LDAP implementation provided as a reference. Map adjuster authority levels, such as payment limits, to groups your HR and identity systems already maintain. Decide who can reassign a case, and confirm that the engine's checks are backed by your own authorization rules.
Actuator and REST monitoring
Claims operations need to see stuck cases, failed jobs and backlog size before a service level is missed. The Spring Boot starters expose an actuator endpoint at /actuator/flowable for monitoring running processes, and the REST layer can feed dashboards and reports. Decide which metrics go to your operations team and which go to compliance, and restrict the endpoint to internal networks. Confirm the Spring Boot version your chosen Flowable release supports before you wire up alerts.
How SLA timers and escalations run reliably across nodes
Claim response deadlines and complaint escalations in a Flowable process are timers, and timers only fire if the engine's async executor picks them up. The executor runs timers and asynchronous jobs from a thread pool, and it coordinates multiple nodes through lock owners and lock expiration times stored in the database. When a node takes a job, it records itself as the lock owner with an expiry time. If that node crashes before finishing, the lock expires and another node picks the job up. For an insurer, this means an acknowledgement deadline or a 30-day complaint escalation timer should not be lost because one application server restarted. Confirm the timer and job tables and lock settings for your Flowable version in the Flowable advanced documentation before you commit to deadlines in your design.
Start with the business rules that the timers encode. Decide which deadlines are hard regulatory or contractual dates, which are internal targets, and what should happen when a timer fires on a case that has already closed. In CMMN, a timer can be attached to a plan item or a milestone, so the design choice determines whether an escalation fires against a stage that no longer applies. Define who owns the escalation path, such as a claims supervisor or a complaints team, and whether the escalation is a new task, a reassignment or a notification. Then test the behavior in your own environment: stop one node during a pending timer, confirm another node fires it after lock expiry, and check that the audit history shows one firing, not two. Test with the database you will run in production, because the Flowable configuration docs list the supported types (H2, MySQL, Oracle, PostgreSQL, DB2 and Microsoft SQL Server) and note that MySQL versions below 5.6.4 lack millisecond precision, which affects timer accuracy.
How an insurance Flowable rollout is phased
The sequence moves from agreed claim and underwriting decisions to a controlled release and a handover your operations team can run, with each phase closing on a check that the business and compliance owners can sign off.
Scope claim and underwriting decisions
Business owners for claims and underwriting, with compliance and audit representatives, agree which decisions, handoffs and service levels the Flowable application will cover. The team lists the claim types, underwriting lines and complaint paths in scope, names the decisions that must be explainable to a regulator, and records what stays in the existing core systems. This phase closes with a written scope document that the owners approve before any modeling starts. Your team needs to provide named decision owners and access to current procedure manuals and rating guidelines.
Model cases and decision tables
Modelers work with claims and underwriting specialists to turn the agreed scope into CMMN case models for claim lifecycles, with stages, sentries and milestones, and DMN decision tables for underwriting eligibility and routing rules. Each decision table is traced back to the source guideline so a reviewer can follow every rule. The phase closes when specialists have walked through the models and confirmed the rules match current practice. Your team provides the guideline text, rating tables and any exception rules that currently live only in staff experience.
Integrate with core systems
Engineers connect the case and process models to the policy administration, claims and document systems that hold the authoritative data. The team confirms which system owns each data element, how calls are made and how failures are retried, using the integration points the Flowable documentation defines. The phase closes when test calls return the expected data for sample policies and failed calls are visible in the engine. Your team provides API documentation, test environments and named contacts for each core system owner.
Map identity and roles
Architects map adjuster, supervisor, underwriter and complaint handler roles from your directory to the groups and permissions used by human tasks and decision steps. The team confirms how four-eyes approvals and authority limits are enforced in the application and where the engine leaves authorization checks to your code. The phase closes when a role matrix is signed off and test users can reach only the tasks their role allows. Your team provides the directory structure, the authority matrix and the identity provider integration details.
Test with historical claim samples
Testers replay a sample of closed claims and underwriting files through the new models and compare the outcomes, routing decisions and timer behavior with what staff actually decided. Differences are classified as model defects, data issues or policy questions for the business owners to resolve. The phase closes when the owners accept the results and the differences are documented. Your team selects the samples with compliance input, provides anonymized or approved data, and confirms the test records are handled under your data protection rules.
Release in a controlled way
The team deploys process and case definitions through your change process, starting with a limited group of users or lines of business agreed in advance. Operators watch job execution, failed tasks and audit events during the controlled period, and a rollback path is rehearsed before go-live. The phase closes when the owners confirm the limited release meets the agreed criteria and the wider rollout is approved. Your team provides change approvals, a release calendar and production access for the people who will monitor the release.
Hand over to operations
Engineers transfer runbooks for failed jobs, monitoring endpoints, log review, audit evidence and definition deployments to your platform and operations teams. Owners of business rules agree how decision tables are changed, tested and approved after go-live. The phase closes when your operators have run the runbooks in a supervised exercise and the support ownership is recorded. Your team provides named operations owners, on-call coverage and a decision on who approves future rule changes.
Compliance evidence insurers should plan for
Insurers running claims and underwriting on Flowable need evidence that spans third-party contracts, access to the engine, personal data held in process variables, and whether the regulations apply to them at all. The four areas below connect because the same Flowable history, configuration and hosting decisions feed each one. DeployOpen prepares the controls and evidence, while independent auditors and regulators assess them.
DORA register and provider contracts
DORA Article 28(3) requires a register of information covering all contractual arrangements for ICT services, and Article 30(2) requires each ICT services contract to state where services are provided and data is processed. For a self-hosted Flowable estate, the register should list the cloud, database, hosting and support providers behind the claims platform, along with their contract terms on data location, change notice and data return. Confirm with your legal and third-party risk teams which of your entities fall within DORA's scope.
Exit strategies for critical ICT services
Where a Flowable deployment supports a critical or important function, DORA Article 28(8) expects documented exit strategies and transition plans that have been tested. Plan how claims case data, running instances and history would move if a hosting or database provider were replaced. Ask DeployOpen to document the export path for process definitions, CMMN case models, DMN decision tables and history tables, and ask your team to rehearse it before it is needed.
Access and change controls the engine depends on
Auditors testing IT general controls look at who can change process definitions, who can deploy them, and who can reach the engine REST APIs and administrative accounts. Flowable leaves authorization checks to your application, so role mapping between your identity provider and task assignments must be designed and tested. Document the deployment pipeline, approval steps for new model versions, and removal of default accounts, and keep the evidence for each change.
GDPR controls for claimant data
Claims files often hold health details, injury descriptions, bank details and third-party information, and that data tends to end up in process variables and history tables. Under GDPR, the controller must be able to show lawful processing, minimization, retention limits and security of processing. Map which variables carry personal data, decide how long history is kept, and confirm whether data subject requests can be fulfilled across running instances and archived history. Your data protection officer should own the sign-off.
NIS2 applicability checks
NIS2 applies by sector and size, and member states set their own transposition, so an insurer should not assume the status of its group entities. Check whether the insurance business falls within the directive's covered sectors and thresholds in each jurisdiction, and whether the Flowable platform sits inside a service that is in scope. If it is, expect requirements for risk management, incident reporting and supplier security to apply to the claims stack. Confirm the position with national authorities or counsel.
What insurers ask before hiring a Flowable partner
What drives implementation effort for Flowable claims and underwriting?
Effort is driven mainly by how many claim types, lines of business and underwriting rules you need to model, and how many systems the case and decision logic must call. Claims work usually involves CMMN case plans with stages, sentries and milestones, while underwriting usually involves DMN decision tables with hit policies that must be reviewed by underwriters. Other drivers include the number of policy, billing and document systems to integrate, the complexity of SLA timers and escalation paths, and how many custom front ends adjusters will use. Ask any partner to break the estimate down by case type, decision set and integration, and to state which of these assumptions they have tested against your own claim files.
Can our internal engineering team build Flowable claims workflows alone?
Yes, a capable Java team can build on the Flowable engines alone, since they are Apache 2.0 licensed and offer Java and REST APIs. The harder questions are whether your team has time to learn CMMN and DMN modeling, design the identity integration, set up the async executor and database for clustered operation, and build tests that claims and compliance staff will accept. Many insurers split the work: internal staff own the business rules and daily operations, while an outside partner handles the initial architecture, hardening and knowledge transfer. Confirm with your own engineers which of these skills are present before deciding.
What does the work need from claims and compliance staff?
The build needs named claims subject-matter experts to describe how each claim type moves from first notice of loss to settlement, including exceptions, reserves and referrals. Underwriting teams must confirm decision criteria, referral thresholds and the rationale behind each DMN table, and compliance staff must define which events, approvals and data fields must be retained as evidence. Expect regular review sessions during modeling and a sign-off step before each release. Ask the partner to name the roles, time commitments and decision owners in the written scope, because delays usually come from unresolved business rules rather than from engineering.
How does a fixed-scope Flowable engagement work?
Most DeployOpen engagements are fixed-scope, meaning scope, deliverables and timelines are agreed in writing before work starts. For an insurance project, the written scope should list the claim and underwriting processes in scope, the decision tables, the integrations, the environments, the training and the acceptance criteria. Changes that add case types, rules or integrations should go through a written change request with its own effort and timeline. Ask how assumptions about data quality, source system access and staff availability are recorded, and what happens when a client dependency slips.
What does ongoing Flowable support cover after go-live?
Ongoing support is available as a retainer and typically covers monitoring, failed job handling, upgrades, security patching and changes to rules and models. For insurance, retainers should also cover updates to decision tables when product terms or regulations change, and periodic review of audit history and access controls. Operational questions include who responds to failed async jobs or stuck SLA timers, how quickly rule changes are tested, and how release notes from new Flowable versions are assessed. Ask the partner to describe the response process and the reporting you will receive, and confirm these terms in the agreement rather than assuming them.
How does migration from Camunda 7 or Activiti fit an insurance project?
Flowable's engineering blog from September 7, 2022 states that Camunda 7 and Activiti data can be migrated to Flowable in place, including active process instances and history. For insurers with open claims, this matters because running cases can continue rather than being closed and restarted. Flowable offers the free Flowable LEAP tool to report in advance what a migration involves. Confirm which engine versions and data stores you run, how long history must be kept for regulators, and how the migration will be tested against open claims before cutover. Note that Flowable 8.0.0, released February 27, 2026, requires Spring Boot 4 and removes support for Spring Boot 3, so plan that baseline into the target version.
What does DORA change for contracts with an implementation partner?
DORA, Regulation (EU) 2022/2554, has applied since January 17, 2025 to insurers and other financial entities. Article 30(2) requires every ICT services contract to state where services are provided and data processed, to give advance notice of changes, and to cover data return on insolvency or termination. Article 28(3) requires a register of information on all contractual arrangements for ICT services, and Article 28(8) requires documented, tested exit strategies for services that support critical or important functions. Ask your legal and risk teams to review partner contracts against these articles, and confirm where your engagement records would be stored. DeployOpen prepares systems and evidence, but it does not issue attestations, so confirm with your auditors what they will accept.
What audit trails must show for complaints and regulators
An audit trail for a claim or underwriting decision must let you reconstruct, months later, which rule version ran, what inputs it saw, what the adjuster or underwriter did, and what the timers did. Flowable history is the starting point, but it only records what the process and case models were designed to emit. Decide that list before build, not after a complaint arrives. For each decision type, write down the facts a reviewer would ask for: the DMN decision key and deployed version, the input values passed in from the case or process variables, the outcome returned, the human task claim, completion and reassignment events, and any SLA timer that fired, was cancelled or was overdue.
Retention and history settings are a deliberate choice, not a default you inherit. Confirm in the Flowable configuration and advanced documentation which history level your engine runs at, how much detail each level keeps for process and case instances, and whether history cleanup or archiving would remove records your retention policy requires. Also confirm how timer jobs record their outcome and how the async executor handles failed or retried timers, because a missing timer record is hard to explain to a regulator. Test a restore of a closed claim from your backup, not only from the live database, and check that the decision version it cites still exists in your deployment history. Variable values that hold personal or health data need the same retention and access decisions as the rest of the claim file.
How DeployOpen scopes and delivers Flowable for insurers
DeployOpen plans, builds, hardens and documents Flowable claims and underwriting applications inside the insurer's own infrastructure. Each engagement starts from a written scope that names the case types, decision tables, human tasks, timers and audit evidence the business needs, so the delivery team and the claims and underwriting leads agree on what is built before work begins.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists which claim and underwriting cases, decision tables and adjuster tasks are in and out of the build.
- Scoping maps SLA timers, escalation paths and complaint records to the systems and owners that hold them.
How we build
- Build covers CMMN case models, DMN routing rules and BPMN tasks, with delegates for policy, claims and document systems.
- Identity integration is set up against your directory, with role mapping for adjusters, underwriters and supervisors.
- Testing includes unit tests for delegates, decision table tests and scenario runs for timers and reopened claims.
How we hand over
- Handover includes deployment scripts, configuration for your database and runbooks for failed jobs and restarts.
- Documentation records decision table versions, process definitions and the history data kept for complaints and regulators.
- Your team receives a walkthrough of how audit history is queried and exported for internal audit and examiners.
How we support
- Ongoing support, version upgrades and continuous testing are available as retainers after handover.
- Support can cover Flowable release upgrades, planned Java and Spring baseline changes and rule changes from underwriting.
- Ask your DeployOpen contact to confirm response arrangements and which environments a retainer covers in writing.
