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.
• Restore related peer assets, including sandbox files, by returning to an earlier version when needed.

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

1. Open the Peer or Flow in Studio.
2. Review the configuration, permissions, connected data sources, tools, and final outputs.
3. Test the draft with realistic inputs.
4. Add a clear change note if Studio asks for one.
5. Publish the version.
6. 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.

For Peers that use sandbox files, treat file changes as part of the version you are publishing and verify the expected file set before you publish.

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.
• For Peers that use sandbox files, whether the version matches the file set you expect to restore.

Roll back safely

Rollback is useful when a recently published version causes an unexpected result.

1. Open version history.
2. Choose the known-good version.
3. Review what will change before restoring it.
4. Roll back or restore from that version.
5. Test the restored behavior.
6. Tell affected teammates what changed.

For Peers that use sandbox files, confirm the restored version also brings back the matching file set you expect before you resume production use.

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.
• If a Peer depends on sandbox files, test both the current files and a rollback path before publishing major changes.

For technical implementation

Use the Developer Hub for API automation, endpoint behavior, version queries, rollback automation, response formats, and scripted release workflows.

Related pages

• Run and Share Flows
• Evaluation System
• Peer Settings