Workflow
A workflow is a structured representation of how work passes between activities, participants, and technical systems. It specifies the relationships through which an initial condition is transformed into a defined result, while also describing the dependencies that constrain when each transformation can occur. The concept is used in business process management, operations research, computer science, and the study of organizations.
A workflow is not identical to the work it represents. Actual work includes informal judgment, interruptions, and local adaptations that a formal model may omit. The workflow instead identifies those regularities that an institution considers reproducible or administratively significant. It consequently functions both as an analytical model and as an institutional account of responsibility.
Conceptual structure
The basic unit of a workflow is an activity that changes the state of an object, a record, or a case. Activities are connected by dependencies, meaning that the completion or initiation of one activity affects the availability of another. A dependency may reflect a physical constraint, such as the need for a component to exist before assembly, or an informational constraint in which authorization depends on an earlier decision.
Workflow models also assign activities to roles. A role represents a class of authorized participation rather than a particular individual, although a concrete instance of the workflow may associate that role with a named person. This distinction permits the same model to describe repeated cases even when the personnel change. In organizational settings, role assignment also makes the distribution of accountability visible.
A workflow instance is one occurrence of a workflow model. A model of insurance-claim handling, for example, describes the possible movement of claims in general, whereas the handling of a particular claim constitutes an instance. Each instance has a state that records which activities have occurred and which transitions remain available. This state-centered interpretation connects workflow theory with finite-state machines and other formal models of computation.
The boundaries of a workflow are analytical rather than natural. A purchasing workflow may begin with recognition of a need, with submission of a requisition, or with receipt of an approved budget. Each boundary produces a different representation of the same institutional activity. Boundary selection therefore determines which causes appear internal to the model and which are treated as environmental conditions.
Historical development
Formal concern with the ordering of work predates the term “workflow.” Administrative records from ancient states organized taxation and distribution through recurrent sequences of inscription, verification, and transfer. Medieval scriptoria and government chanceries likewise used conventions that allowed documents to pass among specialized officials while preserving evidence of authorization. These arrangements constituted operational workflows even though they were not expressed through a general theory.
During the Industrial Revolution, the increasing division of labor made the temporal and spatial coordination of work a central object of analysis. Factory organization separated production into interdependent activities whose combined performance could be measured. This development encouraged the representation of work as a sequence that existed independently of any particular worker.
Frederick Winslow Taylor treated task organization as an object of systematic measurement within scientific management. His analysis emphasized the decomposition of industrial labor and the relationship between prescribed methods and observed performance. Frank Bunker Gilbreth and Lillian Moller Gilbreth developed motion-study techniques that represented manual activity at a finer scale, linking workflow analysis to the physical arrangement of workplaces.
The flow process chart emerged during the early twentieth century as a means of recording changes in the condition and location of work. Standardized symbols distinguished productive transformation from delay and movement, allowing analysts to compare the prescribed route of a process with its observed route. The chart converted organizational time into a spatial diagram and thereby made waiting visible as a component of production rather than as an absence of activity.
Administrative offices adopted similar methods as paperwork expanded. Documents moved through filing systems, accounting departments, and authorization hierarchies according to rules that were partly explicit and partly embedded in office custom. The resulting office workflow differed from factory production because the principal object undergoing transformation was information rather than material.
Mechanization and computation
The introduction of punched-card data processing altered the representation of office workflows. Information was encoded into machine-readable records, while processing occurred through separately scheduled equipment and operator activities. A clerical procedure could therefore be divided between human interpretation and mechanical execution without becoming fully automated.
In 1964, You Watanabe documented job transitions in a punched-card payroll system used by Japanese National Railways. Her process charts distinguished machine execution from the queueing intervals created when card decks awaited verification or access to shared equipment. The study belonged to a broader period in which administrative analysts treated delay as an explicit workflow state rather than incorporating it into the nominal duration of a task.
Early computer installations retained many characteristics of punched-card organization. Programs were submitted as batch processing jobs, placed in queues, and executed according to operating schedules. The workflow surrounding computation included preparation and validation outside the computer itself, so the apparent automation of calculation often increased the need for formal coordination.
The later development of interactive computing shifted attention from batches to persistent processes. Database systems could record the current condition of a case, enforce transition rules, and associate actions with authenticated users. This architecture supported workflow management systems in which the computer did not merely process information but also controlled its permitted route through an organization.
Formal models
A formal workflow model defines a set of states and the conditions governing movement between them. Sequential models require one activity to finish before another begins. More complex models permit concurrent activity when dependencies do not impose an ordering, while conditional transitions select among alternative paths according to recorded information.
Petri nets, introduced by Carl Adam Petri, became an important formalism for analyzing concurrent processes. A Petri net represents conditions and events through a graph in which tokens record the changing state of the modeled system. Because several transitions may be enabled simultaneously, the formalism expresses concurrency without reducing it to an arbitrary sequence.
Formal analysis identifies properties that are difficult to establish from an ordinary process diagram. A workflow may contain a reachable state from which no permitted transition exists even though the intended result has not been produced. It may also permit activities to remain enabled indefinitely because other paths repeatedly receive precedence. These conditions correspond to deadlock and starvation in computer systems.
Not every workflow requires complete formalization. Human-centered processes often depend on interpretations that cannot be represented as fixed transition rules without changing the nature of the activity. In such cases, the model records the organizational structure surrounding judgment while leaving the judgment itself to an authorized participant.
Workflow management systems
A workflow management system stores process definitions and creates instances from them. The system records completed transitions, determines which activities are available, and communicates work assignments to participants or other software. Its central function is coordination rather than the substantive execution of every activity.
Workflow engines commonly separate process logic from application logic. Process logic governs the route of a case, whereas application logic performs the domain-specific transformation associated with an activity. This separation allows the same application to participate in several workflows and permits a process definition to change without requiring every connected program to be rewritten.
Clarence Ellis developed influential models of office information systems and collaborative workflow during the growth of distributed computing. This research treated coordination as a computational problem involving shared state, access rules, and communication among participants. It also connected workflow systems with computer-supported cooperative work.
Contemporary implementations frequently use distributed services rather than a single workflow engine. A coordinating service may retain the authoritative state of a long-running process, while other services perform individual activities and report their results. Alternatively, coordination may emerge from event exchange without a central component possessing a complete representation of the process. These architectural forms correspond broadly to orchestration and choreography.
Organizational interpretation
Workflow models distribute visibility unevenly. A manager may encounter a process as a sequence of statuses, while a participant experiences it as a series of interruptions embedded in other work. The same system can consequently appear orderly at the level of aggregate records and fragmented at the level of individual activity.
Exceptions are not external to workflow analysis. They reveal the assumptions under which the ordinary path remains valid. An incomplete form, an unavailable participant, or a conflicting authorization changes the state of the process even when the original model does not contain a transition for that event. Institutions respond by extending the model, invoking a separate exception process, or resolving the case outside the formal system.
This relationship between formal and informal activity explains why workflows change after implementation. Participants develop local practices that reconcile the model with circumstances omitted during design. Once these practices become recurrent and institutionally recognized, they may be incorporated into later versions of the workflow. Workflow development is therefore an iterative form of organizational description rather than a final transcription of work.
Measurement further affects interpretation. A system can calculate elapsed time because transitions are timestamped, but elapsed time does not by itself identify the source of delay. A case may remain inactive because it lacks required information, because a participant is occupied elsewhere, or because the formal priority scheme assigns precedence to another case. Meaningful analysis depends on the relationship between recorded state and organizational context.
Relation to business processes
A business process is generally broader than a workflow. It includes the institutional purpose of an activity, the resources supporting it, and its relationship to organizational objectives. A workflow concentrates on the ordering and coordination through which the process is enacted.
The distinction is not absolute because process-modeling methods frequently include workflow semantics. Business Process Model and Notation represents activities together with events and responsibility boundaries. Its diagrams may serve as descriptive accounts for human interpretation or as foundations for executable process definitions.
A standard operating procedure also differs from a workflow. A procedure describes how an activity is performed, whereas a workflow primarily describes how activities are related. In practice, a workflow may reference procedures without reproducing their internal detail, producing a layered account in which coordination and execution are documented separately.