Workflow builder and reviewer
Validate, test, publish, and roll back with evidence
Validation checks whether a definition is structurally ready. Testing checks whether business facts take the expected path. Publishing makes a version eligible for live triggers. These are separate decisions and should leave separate evidence.
Before you start
- An inactive workflow draft.
- Fictional payloads for qualified, unqualified, and invalid cases.
- A running queue worker and scheduler.
#Validate structure first
Run validation and fix every missing mapping, unsupported node, unreachable path, permission requirement, and provider prerequisite. Read warnings as design feedback. Do not publish merely because the canvas looks connected.
#Test a small decision table
| Case | Input | Expected path |
|---|---|---|
| Qualified | Automation, $7,500 | Manager approval |
| Ordinary | Automation, $2,000 | Normal follow-up |
| Different service | Training, $7,500 | Normal follow-up |
| Invalid | Budget missing | Validation/failure route |
#Publish as a controlled release
- Save the final draft and create a version snapshot.
- Review permissions, approvals, connector health, workers, scheduler, and failure owner.
- Publish the approved version.
- Trigger one safe live-like event.
- Inspect its execution before increasing volume.
#Use rollback to restore a known definition
Rollback changes the workflow definition; it does not undo external work already performed. After rollback, validate again and confirm which version is published. Correct duplicate-risk separately using delivery evidence and idempotency.
#Common mistakes
- Testing only the happy path.
- Publishing without a failure owner.
- Assuming rollback reverses emails, tasks, or provider writes.
#Verify the result
- Every decision branch has a test case.
- The published version is identifiable.
- The first execution was reviewed.
- Rollback and duplicate-risk procedures are understood.