FlowKeyOps treats workflow configuration as versioned desired state. This creates a reviewable history around an automation runtime that may otherwise change through an editor or API.
Versioning has two sides
The repository records the version your team considers authoritative. The runtime reports what is currently deployed. FlowKeyOps compares the two and presents their relationship as synchronized, deploying, drifted, failed, or another supported state.
What belongs in a workflow version
A version should capture the workflow definition required to understand logic and configuration. Secret values must not be committed with the workflow. Credential references may identify which managed credential is required, but the sensitive value belongs in the configured secret system.
Version numbers are identifiers, not quality scores
A higher version is newer, but it is not automatically safer or ready for Production. Review the change, validate it in a lower environment, and confirm its dependencies before promotion.
Environment versions may differ
Development can legitimately be ahead of Staging and Production. That difference becomes a problem only when it is unexpected, violates your release policy, or leaves a required fix undeployed.
Keep changes understandable
- Prefer small, purposeful workflow changes.
- Use meaningful change descriptions in the repository.
- Separate credential rotation from unrelated workflow edits when possible.
- Validate environment-specific mappings before promotion.
- Use the audit history to connect a deployed version with its approver and time.
When a runtime edit occurs
An authorized emergency edit may still create drift because runtime no longer matches desired state. Investigate the change, decide whether it should become the new desired version, and record the decision. Do not automatically accept an unexplained runtime change.