An overview of the architecture for an insurance claims loss notice application at Indiana Farm Bureau, using headless Camunda BPM to maintain application state and to drive a multi-screen and completely stateless Angular application. Workflow modeling can take users through multiple paths, and the sequence can be changed without altering the Angular application. This architecture decouples UI concerns from the BPM.

1. Camunda for
Modern Web
Applications
Corinna Cohn
Sowmya Raghunathan

2. What is a “Modern Web
Application”
● Support for multiple implementations (mobile/desktop)
○ Loose coupling between UI and application layer
● Client communicates with server via REST
● Scalable
● Cloud Deployable

3. Use Case: Claims Intake
● A single entry point for loss takers to initiate claims
intake for multiple lines of insurance product (auto,
home, farm, business)
● Improve customer experience by accelerating claims
resolution
● Early detection and notification of business critical
events
● Easy to learn, easy to use, easy to enhance with new
product lines and features

4. Solution: Camunda REST Engine
● BPM was an obvious choice for managing business events
● Service-Oriented Architecture
● However, there were no clear product choices for developing a
UI for BPM interaction
● IFBI has been using Angular for developing responsive,
modern web applications
+

6. Architecture Overview Processing BPMN

7. Parent Process
● Business logic is assembled like
Lego it can be arranged and
connected in many ways
● Provides orchestration between
sub-processes
● Manages application state
● Business analysts can read the
BPMN to understand the
business flow without needing
to understand the
implementation details

8. The Sub-Process
● Defines a specific
business task
○ For example,
evaluating if the
vehicle is total
loss
● State is provided by
parent process

9. Transaction Sub-Process
● Called by the Parent Process
● Receives its application state from the Parent Process
● Executes a Unit of Work
● Reusable (Composable)
● Can have a Wait State for more user input
● Able to orchestrate microservices

10. Gateway
● Separates Camunda from UI implementation
● Implemented as Camunda BPMN initially and re-
implemented as Java service (GaaS)
● Simplifies API for UI to implementation (vs Camunda
REST API)
● Exposes Human Task as a service for the UI
● Provides security layer

11. Gateway Process Camunda
HTTP API
Client HTTP
Request
Gateway Process
2. Gateway Process creates a business key and
starts the Parent Process
3. Parent Process returns list of commands to
Gateway (Camunda HTTP API)
1. Client issues START with process name4. Gateway Process returns simplified payload
and business key
5. Client issues CONTINUE with business key
and valid actions

12. Client Layer / UI
● Based on CQRS pattern
● After starting a process, every screen is loaded based on
an action
● The client contains a map of which components and
screens are loaded for each action
● The Parent Process sends a list of valid actions along with
a payload for resolving those actions
● Client uses actions to determine which functionality to
enable

13. UI: Single Page Application
● The user experience is like a long multi-step wizard
○ User fills out a screen, then hits “Next”
● The “next” screen depends on inputs from the current
and previous screens
● Our architecture completely separates screen order
from the UI

14. Sequence
● Front end initiates “start” (Gateway)
● BPM generates list of available actions
(Parent/Subprocess)
○ Returns a payload with action list and necessary data
● User executes an action from this list (UI)
○ BPM stores the state of the workflow
○ Front-end always receives current state from workflow
● BPM generates list of next actions (Parent/Sub)

15. DEMO
Switch to live presentation
● Show the system running
● Cockpit
● Reiterate the concepts
● Take 1 or 2 questions

16. Benefits of Our Approach
● Business has complete freedom to set requirements
without UI constraints
● Business can reorder, remove, and in some cases
completely change input forms without requiring
corresponding UI changes
● Client developers do not need to understand BPM layer
(and vice-versa)
● Client is implemented independently from the workflow
engine
● All of the benefits of Camunda engine and Cockpit

17. Case: Reordering Screens
● About six weeks before launching the first version of the
Claims Intake application, the business owner asked for a set
of screens to be arranged in a different order.
● Based on previous experience with this type of request, the
business estimated an additional 4 weeks of development
time.
● Due to the flexibility of this architecture, we were able to
complete the work in several days.

18. Case:
Simultaneous
Workflows
● Before submitting a Loss
Notice, the Loss Taker has an
opportunity to review the the
data, where they can make
corrections as needed.
● Parent process is modelled to
have multiple sub-processes in
parallel
● Front-end receives a list of
actions--It doesn’t have an
existing action map, so loads
all components matching the
actions, ordered by the action
list order
● User can interact with
components in any order

20. Challenges of Headless BPM
● Application State Management
● Decoupling Camunda REST API from application domain
○ CAC: We will expand this to talk about the gateway
● Decoupling Application Domain from UI implementation
○ CAC: We will expand to talk about how the contracts give us the
flexibility to choose different UI implementations
● Coherence between BPM workflows and UI screens
○ CAC: This is to talk about the “action-driven” architecture
● Lack of documentation on similar patterns

21. Summary
● Gateway Pattern
○ Decouples BPM from front-end implementation
● Parallel Workflow/Component Architecture
● User tasks as opportunity to build a guided workflow
● Users do not have knowledge of Camunda or Camunda
Forms

22. Thank you
Corinna Cohn
Sowmya Raghunathan