State Machines and BPMN

This guide explains how a finite state machine works, how it differs from Business Process Model and Notation, and how AMODIT applies state-based process automation.

The Role of BPMN

Business Process Model and Notation is a recognized standard for describing workflows with defined symbols, events, tasks, gateways, and interactions. It is valuable for precise models of complex processes.

The challenge begins when a detailed model must become an operating application. The notation can require specialist knowledge, and a complex diagram is often difficult for process participants outside IT to maintain or interpret.

A State-Based View of Work

A finite state machine represents a process as defined states and permitted transitions. An invoice might be registered, under review, awaiting approval, and approved. This matches the way many employees describe operational work.

Key Differences

• Accessibility: users work with familiar statuses instead of a large symbol set.
• Simplicity: each stage is a state with explicit transitions.
• Flexibility: teams can add a stage or revise a transition rule without redrawing an entire complex flow.

BPMN Strengths and Limits

BPMN handles complex paths, events, decision logic, and interactions with external parties. That precision is valuable in processes that require a formal, shared notation.

The tradeoff is accessibility and maintenance. BPMN 2.0 expanded the modeling vocabulary, but the additional symbols can make diagrams harder for operational users to understand and revise.

Example: Purchase Invoice Workflow

1. Registration: the invoice enters the workflow.
2. Business review: employees confirm the document and its business context.
3. Business approval: the invoice is checked against company policy.
4. Accounting approval: finance verifies accounting requirements.
5. Invoice coding: accounting information is assigned before payment.
6. Posting: the approved invoice enters the accounting records.

An exception can return the invoice to an earlier state. Additional approval can be added for an amount threshold by defining another state and transition rule.

State Machines in AMODIT

• Business rules: move cases between states based on case data and approved actions.
• Automation: check defined conditions and issue reminders.
• Configuration: add a state or revise transition logic without conventional programming.

Users manage recognizable statuses and rules rather than working directly with a complex notation.

Example: Recruitment

1. Application: the candidate enters the process.
2. Review: HR reviews the résumé.
3. Interview: selected candidates complete the interview stages.
4. Decision: a responsible person approves hiring or rejection.

Each state has explicit conditions, and HR can see the current stage of every case.

Choose the Model for the Process

BPMN remains valuable when precision, many interactions, and complex event logic justify specialist modeling. For everyday case workflows such as invoices and recruitment, a state machine often gives operational teams a clearer model.

Some tools combine both approaches, reflecting the need to match the notation to the process rather than treating one method as universal.

IT Implementation

BPMN

• often uses specialist modeling tools;
• can require a dedicated process engine;
• can be complex to maintain.

Finite State Machines

• have a direct implementation model;
• are straightforward to test state by state;
• support focused changes to transitions.

Current Priorities

• simple and flexible process experiences;
• fast adaptation to change;
• strong user experience;
• integration with automation and AI services.

Clarity for Operational Processes

State machines make many workflows easier to explain, configure, and test. AMODIT combines that model with forms, business rules, permissions, and automation.

Review a Process Model