Deployment Rollback

The Deployment screen is best viewed when the zoom setting is set to 80% on your Chrome/Firefox browser.

About Deployment Rollback

ARM can take a snapshot of your orgs' metadata and copy or deploy it to another org. This will allow you to deploy/rollback changes in a few clicks. The ability to compare two different snapshots (from other orgs) and see the details of what changed can help you track down the cause of problems when they arise.

How can I roll back my deployment?

Before rolling back your deployment, ensure the rollback feature is turned on for your deployment. This implies that the Take Backup checkbox is selected on the Deployment Settings screen when a deployment is run. The deployment will not be able to be rolled back if the checkbox is not enabled.

Next,

1. Go to the Deployment History screen and choose the deployment label from the list for which you would like to trigger the rollback.

2. Click Rollback.

3. Find the metadata components that will be rollbacked (under the Constructive Changes section).

Note: In previous releases, ARM didn't have the option to exclude the members while doing the rollback. However, in the recent release, you will now have the feasibility to exclude/deselect the metadata members from the Constructive Changes section.

4. In the "Choose your Pre/ Post Destructive Changes" screen, you’ll see the list of metadata components present in your target org but not in your source org. Select the checkbox next to a component you want to delete, which is deleted when you deploy. The excluded components' details are logged and can be found in Rollback Iteration Log.

5. You can choose the destructive changes method to delete your components from your target org to sync up the orgs.

   • Post Destructive Changes: The post destructive changes feature will delete the unwanted fields or metadata components from your destination Salesforce org when the deployment is successful.

   • Pre Destructive Changes: Pre-destructive changes will delete unwanted fields or metadata components from your destination Salesforce org before the deployments begin.

   

Point to Remember: You must add the version number before continuing with destructive changes for active flow metadata. See the FlowDefinition guide for more detail.

6. Select the Apex Test level to validate your deployment. For detailed information on each test level, refer to the article: Apex Unit Tests

7. Next, you will find two more deployment options to choose from:

   1. Deploy purge on delete: Salesforce uses a recycle bin metaphor for data that users delete. Instead of removing the data, Salesforce flags it as deleted and makes it visible through the recycle bin. ARM has a provision to identify the components that users want to delete and permanently delete them from their Salesforce environment instead of keeping the deleted components in recycle bin. Once purged, they can not be recovered.

   2. Ignore warnings: This option will allow the rollback to continue even if warnings can cause the deployment to fail.

8. Add information about the current rollback deployment process in the Deployment Notes box.

9. Type 'Rollback' in the field provided and click on Yes.

   
10. After successfully rolling back your changes, your deployment will be stored in the Deployment History section, tagged as a rollback. You can view the usual deployment report from here, download the package, and even re-deploy the rollback if you wish!