Version Control
kikuflow uses an immutable versioning model — every published version is a permanent record that cannot be modified after the fact.
Why this design?
To protect in-progress workflow instances. If a workflow could be changed at any time, running requests could face:
- The reviewer suddenly changed — do previously approved steps count?
- The number of steps changed — how do completed nodes map?
- Audit records can't be tied to any version
Version locking ensures every instance runs to completion using the version that was active when it was created.
Version lifecycle
Draft → Published → Archived- Draft: Generated by the Agent but not yet published — can still be adjusted
- Published: Live and active — members can submit requests against this version
- Archived: Automatically archived when a new version is published — no new requests, but in-progress instances finish normally
Publishing a new version
Tell SuperAdmin Agent what needs to change:
"Update the 'Purchase Request Workflow' — change step 2's reviewer to the Audit Team, and raise the finance manager threshold from $50,000 to $100,000."
The Agent will:
- Generate a new version draft based on the current version
- Let you confirm, then publish
- The old version is automatically archived
Effect of version switch
| New requests | In-progress requests | |
|---|---|---|
| After new version is published | Follow new version | Continue on old version until complete |
Transition period is normal
Having both old and new version instances running simultaneously is expected. The system maintains execution state for both versions until all old-version instances are complete.