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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
You can combine approaches to get the best of both worlds.
Version
Description
1.2.0-order-retry-logic
Semantic version with feature context
2026-03-09-hotfix-auth
Date-based with change summary
2.0.0-rc1
Release candidate before a major version
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.
