Workflow Models: Structuring Tasks, Decisions and Transitions

What Is a Workflow Model?

Business Process Model and Notation (BPMN) defines a process as a sequence or flow of activities through which work is carried out in an organization. In BPMN, this process is represented as a graph of activities, events, gateways, and sequence flows. The specification explicitly allows different levels of detail, from an organization-wide process to an individual person's sequence of work.^[1]

In this article, the term workflow model does not necessarily denote a particular notation. A process can also be described using other formal or domain-specific models. BPMN is nevertheless an important reference model because it precisely distinguishes key building blocks and their relationships.

Turning “As Needed” into a Condition That Can Be Decided

An illustrative model for incoming-goods inspection initially contains the instruction “Recheck as needed.” Two people can derive different processes from it. The trigger, responsibility, and what happens pending clarification remain unclear.

The modeling task is to close this gap. One possible operational rule is: if a test report cannot be unambiguously assigned to the delivered batch, incoming-goods inspection hands the case over to the responsible quality role. Use remains blocked until that role's assessment is available. The quality role can confirm the assignment, request additional information, or reject acceptance.

Three things are now separate: the work of “checking the assignment,” the result of that check, and the path that follows. A gateway represents the branch; the substantive assessment must take place beforehand in a task. If the information needed for a decision is missing, the model needs a waiting state or a clarification path rather than a guessed result.

Whether the rule is appropriate can be discussed before implementation using three test cases: report unambiguously assigned, report cannot be assigned, and assessment still pending. For each case, the participants must be able to identify the same next step and the same responsibility. This case review is a working aid, not complete evidence of validation.

The Building Blocks of a Workflow Model

The specific modeling depends on the use case. Nevertheless, recurring elements can be distinguished.

Conditions Must Be Decidable in Domain Terms

A model becomes actionable only when its transition conditions can be decided in the real situation. Phrases such as “as needed,” “check if appropriate,” or “escalate if anything unusual occurs” may seem understandable in a written instruction. For a guided workflow, they remain indeterminate until it is clear who determines the need, which criteria apply, and which next step follows.

A sound condition therefore connects at least:

• the matter to be assessed,
• the permissible results,
• the role authorized to decide,
• the resulting path, and
• the information required as rationale or evidence.

Not every condition has to be calculated automatically. A suitably qualified person can assess an observation and confirm the result. What matters is that the model explicitly provides for this human decision instead of hiding it behind an automatic status change.

For Human in the Loop, this decision point must define which information the person receives, which options they have, and which rights allow them to intervene.

Exceptions Belong in the Process

Many models initially represent only the desired normal path. Real work, however, includes missing information, late results, exceeded limits, equipment failures, deviations, and rework. If these cases are not considered in the model, emails, notes, or informal arrangements arise outside the guided process.

A robust workflow model therefore describes more than the happy path. It defines how an operation is paused, who takes over in the event of a deviation, whether work can be returned, and how the original execution remains connected to review and rework. Termination and controlled completion also need unambiguous meanings.

This does not require anticipating every conceivable disruption as a separate branch. Models become unreadable when they fully draw out every rare variant. A clear basic structure with defined exception and escalation mechanisms is more useful, allowing the specific circumstances to be recorded and substantively assessed.

Model and Execution Are Different Levels

A workflow model describes what is intended, permissible, or required. Actual execution, by contrast, shows what happened in a specific operation. This distinction is fundamental.

A model may specify, for example, that a measurement is followed by either release, another test, or a hold. In a specific batch process, however, only one of these paths was followed. The model contains the possible paths; execution contains the actions and decisions that actually took place.

The W3C PROV data model also separates these levels. It defines a plan as an entity representing a set of intended actions or steps to achieve a goal. An activity, by contrast, is something that actually occurs over a period of time and acts upon or with entities. PROV can connect an activity to a responsible agent and the underlying plan.^[2]

For digital systems, this means that an approved workflow model must not later be treated as though it had already been executed. Conversely, a final status alone cannot reliably reconstruct which intended path was actually taken. The model and its execution data must remain connected but conceptually separate.

Versions and Applicability

Workflow models change. Tasks are reordered, responsibilities change, limits are adjusted, or new checks are added. For ongoing and completed operations, it must therefore remain clear which model version applied.

A new version must not overwrite the historical meaning of processes already performed. If a batch was processed under version 3 in August, version 4 published in September should not create the impression that the earlier process already followed the new rules.

PROV treats a plan as a separate entity. Because plans can evolve, their provenance and versioning can also be described. Explicitly connecting an activity, agent, and the plan used helps validate executions, address deviations from expectations, and provide explanations, among other purposes.^[2] The origin and development of such information are the subject of Data Provenance.

For operations, approval status, validity period, version, and the previous version replaced are therefore relevant at a minimum. Drafting, reviewing, approving, and withdrawing the model are themselves controlled operations.

From a Diagram to an Executable System

An understandable diagram is not yet an executable workflow. Technical execution requires event semantics, data requirements, conditions, roles, permissions, error behavior, and interfaces, among other aspects, to be described with sufficient precision. BPMN therefore distinguishes non-executable private processes for documentation from executable processes that contain additional execution details.^[1]

Weske frames this transition as the step from an operational process model to an executable workflow model: technical information is added for execution, including information about the execution environment of activities. The workflow model therefore remains the blueprint for runtime rather than the record of one concrete execution.^[3]

Even a formally executable model is not automatically suitable for operations. A system can execute a syntactically correct sequence of steps while still representing an inappropriate operational point in time, unclear responsibilities, or insufficient evidence. Modeling must therefore involve the people who are responsible for the process in domain terms and actually perform it.

A Workflow Engine executes an approved definition as a specific instance, persists its state and continues it across human and technical steps.

Nor should every detail of everyday work reside in a central diagram. Domain rules, forms, limits, permission matrices, or material models can be separate, versioned components. The workflow model connects them at the points where they become relevant to the process.

Implementing Workflow Software brings a documented model into routine operation with the people involved, from defining the pilot scope to operational handover.

What Workflow Models Do Not Provide

• Formal correctness does not guarantee substantive correctness. A valid BPMN model can contain unsuitable roles, conditions, or work steps.
• Automation does not eliminate responsibility. Decisions must remain human where expertise, assessment, or legal responsibility requires it.
• More detail does not automatically mean more control. Overmodeling can make processes incomprehensible and changes unnecessarily difficult.

A Model Is Ready When Its Paths Can Be Explained

Before technical implementation, a joint walkthrough with future users is worthwhile: What triggers the process? Which result determines the next path? Who takes over an unresolved case? A model that provides consistent answers creates a verifiable basis for implementation.

The appropriate level of detail follows from these questions. An additional box is helpful if it reveals a previously hidden responsibility or decision. If it merely describes another mouse click, it usually does not improve the substantive process.