Skip to main content
Versions capture the state of your integration at a specific point in time. They give you a reliable way to track changes, roll back safely, and deploy with confidence. This guide covers how to create, manage, and deploy versions in the Versori Platform.
When you save files in the editor, your changes are moved into the latest draft. The latest draft represents the current working state of your integration. When you deploy, unless deploying froma version, it is the latest draft that gets deployed — so always ensure your latest draft reflects the state you intend to release.

​
Why use versions

As your integration evolves — new workflows, updated mappings, revised error handling — you need a way to track what changed and when. Without versions, every edit overwrites the previous state with no way to recover it. Versions solve this by giving you:
  • Change history: See exactly what your integration looked like at any point in its development.
  • Safe rollbacks: Revert to a known working state instantly if a change introduces issues.
  • Deployment control: Choose precisely which version of your integration runs in each environment.
  • Team coordination: Give collaborators a clear record of what changed and why through version names and descriptions.
  • Audit trail: Maintain a log of how your integration has evolved over time for compliance and troubleshooting.
Create versions frequently — especially before and after significant changes. Treat them like save points that you can return to at any time.

​
Creating versions

A version requires a name and accepts an optional description. The name identifies the version at a glance, while the description provides a summary of what changed — making it easier to understand the purpose of each version when reviewing history.
Versions are shared across all available environments and can be deployed to any environment.

​
Manual version creation

You can create a version at any point during the development of your integration. This is useful when you want to checkpoint your work before making a large change, or when you reach a stable milestone worth preserving.
1

Open the Version History popover

Navigate to your project and select the Version History popover in the header.
Version History popover showing a list of versions with their status, date, and description

The Version History popover shows all versions with their status and deployment info

2

Create a new version

Click +, enter a name for the version, and optionally provide a description summarising the changes included.
Create New Version dialog with fields for version name and description

Enter a name and optional description for the new version

3

Confirm the version

The version is created as a snapshot of the current integration state. You can continue developing without affecting the saved version.
Use the description field to record the reason for the version — for example, “Added retry logic to order sync workflow” or “Fixed field mapping for customer addresses”. This context is invaluable when reviewing versions later.

​
Automatic version creation on deployment

When you deploy an integration, a new version is automatically created. This ensures every deployment is tied to a specific, immutable snapshot of your integration code and configuration. You do not need to create a version manually before deploying — the platform handles it for you. However, you are still prompted to provide a name and optional description so the deployment version is clearly identifiable.
Deploy Latest Draft to production dialog showing version name, description, and the latest version number

Deploying creates a new version automatically — you provide the name and description at deploy time

Even though versions are created automatically on deployment, you can still create manual versions at any time. Manual versions are useful for checkpointing work-in-progress that you are not yet ready to deploy.

​
Switching between versions

You can switch between any previously created version to review its state or restore it as the active working version. This is particularly useful when comparing changes across versions or when you need to return to an earlier implementation.
1

Select a version

Choose the version you want to switch to. You can use the name and description to identify the correct version.
2

Review or restore

Review the integration state captured in that version. If you want to you can continue working from this version.

​
Rolling back to a previous version

If a recent change causes issues — failed executions, incorrect data mappings, or unexpected behaviour — you can roll back to a previous version to restore a known working state. Rolling back replaces the current integration state with the selected version. This is the fastest way to recover from a problematic change without manually undoing edits.
Rolling back does not delete any versions. All previously created versions remain available, including the one you rolled back from. You can always switch forward again if needed.

​
Deploying a version

When you deploy an integration, the platform creates a new version. This means every deployment is traceable back to a specific version. You can also deploy a previously created version to an environment without making further changes — useful when promoting a tested version from development to production.
1

Choose the version to deploy

From the Version History popover, select the version you want to deploy. If you are deploying your current work, the platform creates a new version automatically.
2

Select the target environment

Choose which environment to deploy to (e.g. development, staging, production). Each environment runs independently with its own connections and credentials.
3

Confirm the deployment

Review the version details and confirm the deployment. The selected version becomes the active version in the target environment.
Combine versions with environments to build a robust promotion pipeline. Create and test versions in development, then deploy the verified version to staging and production.

​
Version naming strategies

A consistent naming convention makes it easier to identify versions at a glance, communicate changes across teams, and maintain an organised version history. Below are some common strategies.

​
Semantic versioning

Use a structured major.minor.patch format to communicate the scope of changes.
Semantic versioning works well when your integration has external consumers or when you need to clearly signal the impact of each change.

​
Date-based versioning

Use the release date as the version name for a chronological record.

​
Feature or milestone naming

Name versions after the feature or milestone they represent for a human-readable history.

​
Combining strategies

You can combine approaches to get the best of both worlds.
Pick a naming convention early and stick with it across your team. Consistent naming makes it significantly easier to navigate version history as your integration grows.