Peer and Flow Versioning
Cognipeer keeps version history for Peers and Flows so teams can publish stable work, review earlier changes, and roll back when a change does not behave as expected.
What this is
Versioning separates work in progress from the version your team relies on. Drafts let you edit and test. Published versions give teammates and connected workflows a stable configuration to use.
For API automation or endpoint-level version management, use the Developer Hub.
What versioning protects
Versioning helps teams:
- Test a Peer or Flow before it affects other users.
- Keep a known-good version available.
- Understand who changed a configuration and why.
- Restore a previous setup without rebuilding it manually.
- Coordinate changes across teams that depend on the same Peer or Flow.
Drafts and published versions
| State | What it means |
|---|---|
| Draft | Editable work that is not yet the stable version for users. |
| Published | A tested version that users, Peers, schedules, or shared workflows can rely on. |
| Latest published | The published version currently treated as the stable version. |
A draft can change often. A published version should represent a deliberate checkpoint.
Publish a version
- Open the Peer or Flow in Studio.
- Review the configuration, permissions, connected data sources, tools, and final outputs.
- Test the draft with realistic inputs.
- Add a clear change note if Studio asks for one.
- Publish the version.
- Confirm that the newly published version is the one your team should use.
For Flows, test both the expected path and important branches such as rejected approvals, missing inputs, or tool errors.
Inspect version history
Use version history when you need to answer what changed or compare the current behavior with an earlier setup.
Look for:
- Version number or publish time.
- Change notes.
- The user who created or published the version.
- Configuration differences that explain a behavior change.
- Whether the version was a draft or published checkpoint.
Roll back safely
Rollback is useful when a recently published version causes an unexpected result.
- Open version history.
- Choose the known-good version.
- Review what will change before restoring it.
- Roll back or restore from that version.
- Test the restored behavior.
- Tell affected teammates what changed.
Rolling back should not be used as a substitute for testing. Treat it as a recovery action after you understand which version is safe.
Best practices for teams
- Publish only after the draft has been tested.
- Use short, specific change notes.
- Avoid changing several unrelated behaviors in one publish action.
- Coordinate with owners of connected Peers, Flows, schedules, and integrations.
- Review approval paths and security settings before publishing customer-facing workflows.
- Keep old published versions until your team no longer needs the audit history.
For technical implementation
Use the Developer Hub for API automation, endpoint behavior, version queries, rollback automation, response formats, and scripted release workflows.