- Introduction
- Managing solution projects and packages
- Managing solution deployments
- Best practices
Upgrade or downgrade a solution deployment to a different package version in Automation Cloud.
Before upgrading a production deployment, UiPath recommends validating the upgrade in a dedicated test deployment first. For details, see Validate solution upgrades in a test environment.
The Change version action lets you upgrade a deployment to a newer package version or downgrade it to an older one (rollback).
Downgrading a solution does not delete entities, choice sets, and webhooks.
Open the Change version workflow
-
In Orchestrator, select Solutions at the tenant level.
-
In the Deployments tab, find the deployment you want to update.
Tip:When a newer package version is available for a deployment, the Version column shows an upgrade indicator next to the current version number. You can also select Upgrade directly from the row to start the flow.
-
Select the three-dot menu (⋮) at the end of the row, then choose Change version.
The Change version workflow opens on the Setup form.
Complete the Setup form
The Setup form is pre-filled with the current deployment details. Review and update the following:
| Field | Description |
|---|---|
| Package | The solution package associated with this deployment. Read-only. |
| Version | The target package version. Defaults to the latest published version (or the most recent version other than the one currently installed). Select a different version from the dropdown to upgrade or downgrade to a specific version. |
| Deployment name | The name of the existing deployment. Read-only. |
Select Change version to proceed, or select the dropdown arrow and choose Customize to open the resource explorer and review component changes before running the operation.
Review component changes
When you select Customize, the resource explorer shows a summary of what will change:
-
Newly added components, marked with a plus (+) icon. These components will be created in the target environment after the version change.
If the target version adds a component with the same name as one this version change removes, the name conflict no longer blocks the operation: the name becomes available once the removal is confirmed. The conflict still blocks the version change if the resource with that name is not being removed.
-
Removed components, marked with a minus (−) icon. These components will be removed from the target environment unless they are referenced by other solutions. In that case, the components remain in the environment but are removed from the solution.
Removing a queue or storage bucket is blocked if something outside this version change still depends on it: a queue cannot be removed while a trigger that survives the version change still uses it, and a bucket cannot be removed while a queue, task catalog, or process that survives the version change still uses it as a retention target. Remove the dependent component in the same version change to proceed.
If removing a queue or storage bucket would delete its last reference (it is not shared into any other folder), you must confirm the deletion before the version change can run. See Confirm the deletion of replaced resources below.
-
Edited components, marked with an asterisk (*) icon. The Compare property differences panel highlights all property-level changes.
Components with changes only to configurable properties are not marked as edited. Edited components retain their existing configuration values for configurable properties by default, but you can switch to using the package configuration. To review all property-level changes, use the Compare property differences panel.
Optionally edit any configurable component properties, then select Continue to change version to run the operation. For connection components, the authentication type property is presented as radio cards, each showing the option's title and description, instead of a dropdown.
Link, change, or unlink a resource
When the resource explorer is open, you can link a component to an existing resource, change which resource it's linked to, or unlink it, before the version change runs. Unlinking removes the connection between the solution and the external component; at upgrade time, the resource is created fresh inside the solution folder instead of reusing the linked component.
This also applies to a resource that a previous version installed automatically: the link control no longer appears locked for these, and you can link them the same way as any other unlinked resource. Linking an installed resource is supported for the following resource types:
- Process
- Asset
- Storage bucket
- Queue
- Webhook
- Connection
- Index
Linked components are marked with a Linked badge in the resource explorer. Selecting a linked component shows a card with the linked resource's information, including a Tenant chip if the resource lives at the tenant level rather than in a folder.
To link, change, or unlink a resource:
- In the resource explorer, select the component.
- Select one of the following:
- Link to existing to link an unlinked component.
- Change to link a linked component to a different resource.
- Unlink to remove an existing link.
A resource cannot be linked to its own installed copy.
For details on the Link to existing picker, see Link, change, or unlink a component in Deploying a solution.
Result: After unlinking, the resource is created fresh inside the solution folder at upgrade time unless you link it to a different existing component before applying the version change. After the version change is applied, the resource can no longer be relinked.
When you link a resource that a previous version installed automatically, the installed copy is retired: it's permanently deleted, together with its data, once the version change runs. See Confirm the deletion of replaced resources below.
Confirm the deletion of replaced resources
Linking an installed resource to an existing one, or removing a queue or storage bucket that has no other reference, permanently deletes the replaced resource and its data. Before the version change can run, you must confirm this loss.
An inline alert appears above the action buttons, listing the affected resources. Select Delete and deploy to confirm and continue, or use Validate or Save as draft to change the configuration instead. If you change the configuration after confirming, the alert reappears for a fresh confirmation.
If the version change is started without this confirmation (for example, through the API), the operation is rejected.
Deleted resources are not recovered by a later rollback. Rolling back re-creates the resource from the solution package as a new installed resource, without its previous data.
After the version change
You can monitor the operation status in the Deployments tab. For details on all statuses, see Deployment statuses.
After a version change, the deployment status is Inactive. Inactive deployments are further classified as Inactive (Ready to activate) or Inactive (Needs setup to activate), depending on whether additional configuration is required before activation. You must manually activate the deployment for the solution to become functional.
Result: The deployment is upgraded or downgraded to the selected version. The Deployments tab shows Change version - Successful in Last operation, and the Version column reflects the new version.