Model runtime behavior as sequence-style workflows over your objects.
Where objects and links describe structure, workflows describe behavior: how a request or process moves across objects over time. Workflows render as sequence diagrams and reuse the same objects you already modeled.
Where workflows live
Workflows are declared under the model and stored as workflow artifacts (.wf) using sequenceDiagram syntax:
# in the model root
workflows:
checkout:
type: wf
title: Checkout
diagram:
syntax: sequenceDiagram
file: checkout.wf| Field | Purpose |
|---|---|
type: wf | Marks the entry as a workflow |
title | Display name |
desc | Optional description |
diagram.syntax | sequenceDiagram |
diagram.file | The .wf source file |
tags | group:value classification |
Participants are model objects
Workflow participants resolve to objects in the model. Because of this, a workflow stays consistent with structure:
Reference real objects
Participants map to object paths, so messages connect actual systems and components.
Order the messages
The sequence defines step order, arrows, and replies.
Read it as steps or a diagram
The same workflow renders as a sequence diagram and as an ordered steps view.
Structure and behavior stay aligned
Because participants are model objects, a workflow that references a renamed or removed object surfaces as an unresolved participant — a prompt to keep behavior and structure in sync.
When to use workflows
- Request/response lifecycles across services.
- Cross-component processes (checkout, onboarding, provisioning).
- Handoffs that span teams or systems.
Keep one workflow per process. Several focused workflows are easier to read and maintain than one diagram that tries to show everything.
Last updated on