Aexol workflows define state machines with transitions, making it easy to model business processes, application flows, and state management.
workflow OrderFlow {
Pending -> Processing
Processing -> Shipped
Shipped -> Delivered
}
Use initial to explicitly set the starting state. If omitted, the first listed
state becomes initial.
workflow TaskFlow {
initial Todo // Explicit initial state
Todo -> InProgress
InProgress -> Done
Done -> Archived
}
workflow ContentFlow {
initial Draft
Draft -> Review
Review -> Published
Published -> Archived
}
A state can transition to multiple targets:
workflow OrderFlow {
initial Pending
Pending -> Processing
Pending -> Cancelled
Processing -> Shipped
Processing -> Cancelled
Shipped -> Delivered
}
States can transition back to earlier states:
workflow DocumentFlow {
initial Draft
Draft -> Review
Review -> Draft // Send back for changes
Review -> Approved
Approved -> Published
Published -> Archived
Archived -> Draft // Revive from archive
}
workflow PaymentFlow {
initial Pending
Pending -> Authorized
Pending -> Failed
Authorized -> Captured
Authorized -> Voided
Captured -> Completed
Captured -> Refunded
Refunded -> Completed
Failed -> Completed
}
workflow ApprovalFlow {
initial Submitted
Submitted -> UnderReview
UnderReview -> Approved
UnderReview -> Rejected
UnderReview -> NeedsChanges
NeedsChanges -> Submitted // Loop back for revisions
Rejected -> Closed
Approved -> Closed
}
Workflows generate type-safe state machine classes. Aexol can produce implementations in TypeScript, Python, Rust, Go, and JavaScript. Generated classes include:
canTransitionTo(state) — check if a transition is validtransitionTo(state) — execute a transition (returns boolean)getCurrentState() — current stateinitial declarationUse Studio or the Remote MCP endpoint to generate code from any workflow.
Combine workflows with type definitions and visitors for complete business logic:
enum OrderStatus {
Pending
Processing
Shipped
Delivered
Cancelled
}
type Order {
id: string
customerId: string
status: OrderStatus
items: OrderItem[]
total: number
}
workflow OrderFlow {
initial Pending
Pending -> Processing
Pending -> Cancelled
Processing -> Shipped
Processing -> Cancelled
Shipped -> Delivered
}
visitor OrderManager {
"create_order" {
"view_order"
"cancel_order"
}
"process_order" {
"ship_order"
"cancel_order"
}
}
workflow PostFlow {
initial Draft
Draft -> Review
Review -> Draft // Send back
Review -> Scheduled
Scheduled -> Published
Published -> Archived
Archived -> Draft // Revive content
}
workflow TaskFlow {
initial Todo
Todo -> InProgress
Todo -> Cancelled
InProgress -> Blocked
InProgress -> Done
InProgress -> Cancelled
Blocked -> InProgress
Blocked -> Cancelled
}
workflow IncidentFlow {
initial Reported
Reported -> Triaged
Triaged -> Assigned
Assigned -> InProgress
InProgress -> Resolved
Resolved -> Verified
Verified -> Closed
Closed -> Reopened // Reopening
Reopened -> Assigned
Assigned -> Escalated // Escalation path
Escalated -> Assigned
}
| Guideline | Good | Avoid |
|---|---|---|
| Descriptive states | AwaitingPayment | State1, State2 |
| Explicit initial state | initial Todo | Letting it default |
| Model all transitions | Pending -> Cancelled too | Only the happy path |
| Focused workflows | Separate OrderFlow + ShippingFlow | One 20-state monolith |
| Align with enums | TaskStatus.Todo matches state Todo | Mismatched naming |
Aexol validates: