Workflows
No-code automation that chains triggers, steps, and conditions to customise rental business processes without writing code.
Coming soon
The workflow engine will let rental companies automate business processes without writing code — defining rules like “when this happens, do that, then that” through a visual step builder in the admin UI.
Each workflow combines a single trigger (domain events, schedules, inbound webhooks, or manual UI actions), an ordered sequence of steps (actions, branching conditions, delays, and human-review halts), and a context object that carries data from the trigger through every step.
This documentation will cover trigger types, step handlers, template syntax for referencing prior step output, and how workflows extend the same event bus that powers audit logs and webhooks.
Authoring, versions, and publishing (P7C-02)
Authoring is built and separate from execution. A workflow's draft lives in workflows + workflow_steps and is always editable; publishing takes an immutable copy-on-publish snapshot into workflow_versions (validated WorkflowSnapshot value object, sequential version_number, published_by / published_at). Runs pin to a version, so draft edits can never rewrite executed history.
| Action | Responsibility |
|---|---|
App\Actions\Workflows\CreateWorkflow |
Create a definition in its unpublished draft state |
App\Actions\Workflows\UpdateWorkflow |
Update the definition header and replace the ordered step list (steps keep their node_key); bumps draft_revision |
App\Actions\Workflows\PublishWorkflow |
Validate the draft (non-empty, registered handlers, handler config schemas) and write version n+1 |
App\Actions\Workflows\ActivateWorkflow / DeactivateWorkflow |
Arm or disarm a published workflow (is_active) |
App\Actions\Workflows\DeleteWorkflow |
Soft delete an inactive definition, retaining versions and run history |
Permissions: workflows.access|view|create|update|publish|delete (see App\Policies\WorkflowPolicy). The admin UI lives at /admin/workflows — see Workflows (admin). Definition lifecycle events (workflow.created, workflow.updated, workflow.published, workflow.activated, workflow.deactivated, workflow.deleted) are recorded on the audit trail and are system-protected until a workflow API surface exists.
Engine-side handler registration (P6-19)
Phase 7 will discover invocable step handlers from App\Services\Workflows\WorkflowActionHandlerRegistry. Core already registers:
| Key | Handler | Notes |
|---|---|---|
export |
App\Actions\Exports\ExportWorkflowAction |
Runs the export engine; delivery hint accepted but in-app only (notification + download link). Mail / SFTP / storage targets are Phase 7. |
Handlers are invocables resolved from the container. Plugins and future core modules register additional keys on the same registry at boot.