Workflow architecture and ownership#
Matrix Workflow coordinates business processes across independent services and human participants. Its administration experience is a Matrix application. The process compiler, execution rules and integration contracts remain separate from Matrix UI components, allowing participants to implement the published contracts without adopting the application framework.
The runtime uses PostgreSQL for durable state and ordinary .NET workers for scheduling, dispatch and reconciliation. RabbitMQ carries integration messages. HTTPS provides an alternative transport for directed participant operations. Redis, where configured, caches eligible immutable metadata; it does not own task state, deadlines or process progress.
Responsibility boundaries#
| Component | Owns | Does not own |
|---|---|---|
| Workflow | Process definitions, activation, instances, tasks, execution history and recovery decisions | A participant's business database or internal algorithm |
| Participant service | Its capability implementation, business effect and authoritative operation receipt | Workflow's scheduler or another participant's state |
| Business application | Its domain rules, persistence, interaction forms and current authorization | Common inbox delivery/read state |
| Messages | Human message content, recipients, delivery and read/dismiss state | Human approval or process completion |
| Portal | Enrolled application launch and its existing preference services | Workflow definitions or business permission decisions |
| Infrastructure | Shared service lifecycle, protected enrollment, credentials and transport allocation | Application transaction boundaries or business correctness |
These boundaries are integration contracts, not shared-table access. A participant should not read or write Workflow tables to advance a process. An application also remains responsible for its own business transaction even when Workflow directs the operation.
Four different records#
A business object, process instance, human task and inbox item represent different responsibilities. An application owns the business object. Workflow links an instance to that subject and records the obligation assigned to a person. Messages publishes an actionable projection of the obligation so eligible people can discover it.
Opening or dismissing that item changes neither the business object nor the authoritative task. Completion follows an authorized owner operation and the appropriate receipt. This separation allows an inbox outage to delay notification without erasing a committed decision.
Design time and execution time#
The process registry groups drafts and published versions under a stable process identity. Publication compiles an acknowledged draft against approved capabilities, schemas and the supported BPMN profile. Activation separately selects a version and starting rule for an environment and tenant.
An instance retains its selected process version, activation revision and execution bindings. Updating a definition or route does not silently redirect waiting work. Current authorization remains a live check even when the contract and binding versions are pinned.
Independent services and transport#
A service exposes a typed capability, durable command handling and a way to query authoritative outcomes. Workflow supplies the outer process coordination. If a participant already orchestrates its internal pipeline, expose an appropriate operation boundary rather than allowing two engines to schedule the same internal steps.
The common transport conventions separate commands, committed business events, durable receipts and human notifications. A broker confirmation proves a transport fact; it does not prove the requested business change completed.
Release and operational qualification#
The product documentation records local implementation and acceptance of designer, service execution, human work and integration administration, with different features tied to specific releases. Historical handoffs describe their own milestone baselines. They are not universal statements about every installation.
Select compatible API, Worker, Web, participant and adapter versions, then verify the assembled environment. Production capacity, high availability, retention and recovery objectives require their own acceptance evidence. Continue with definition lifecycle, participant implementation or human task integration.