Workflow Versioning
Last updated
Last updated
With Workflow Versioning, you can easily manage different versions of your workflows, track changes, and revert to previous versions as needed. This feature allows for better control over workflow updates and ensures stability when deploying changes.
Major and Minor Versions: When deploying a workflow, you can specify whether the new version is a Major or Minor update:
Minor: Used for small updates or bug fixes.
Major: Used for significant changes or new functionality.
Default Version: When deploying a new version, you have the option to set it as the default version. The default version will use the main API URL, allowing users to interact with it without needing to specify a version number in the URL. If a version is not set as default, its API URL will be appended with the version number (e.g., 2.1).
Deploying a Version: When you're ready to deploy changes to your workflow, you can choose to release it as a Major or Minor version. You can also add a comment describing the changes made in this version, helping you and your team keep track of updates.
Version History: The Version History panel (as shown in the images) displays all past versions of the workflow:
Each version shows the name of the user who deployed it, the version number, and the time it was created.
The currently active (deployed) version is labeled as Deployed.
The Default version is highlighted to indicate which version is live and using the main URL.
Previewing Versions: You can preview any previous version of the workflow to see how it behaves. This feature allows you to test older versions without fully reverting to them, ensuring that you can safely evaluate previous functionality.
Reverting to Previous Versions: If needed, you can revert to an older version of the workflow. This action will make that version the active one again, effectively undoing any changes made in more recent versions.
Creating Drafts: When you start making changes to a workflow from any version (whether it’s the current default, deployed, or an older version), a new Draft is automatically created. This draft version will not affect the live workflow until you decide to deploy it.
You deploy Version 2.1 of a workflow and decide to preview the changes.
After some time, you realize Version 1.0 works better for your use case, so you decide to revert back to Version 1.0. The system makes that the active version, and the previous URL mappings remain intact.
Later, when you're ready for new changes, you can edit the reverted version, creating a Draft, and eventually release it as a new version.
Default Version: When a workflow is set as the default, it uses the main URL (e.g., https://your-company-id.lleverage.run/your-api-endpoint).
Non-Default Versions: If a workflow version is not the default, its URL will include the version number (e.g., https://your-company-id.lleverage.run/your-api-endpoint/2.1). This ensures that previous versions can still be accessed while the default version remains active.
Set as Default: Makes a version the default, meaning it will be used with the main URL.
Deactivate: Stops the version from being actively used.
Revert: Rolls back to a previous version, making it the active one again.
Copy cURL: Provides a cURL command for quick testing of the deployed version's API endpoint.