What Is Destructive Changes
Destructive Changes is a Git operation that can be executed from the Git Snapshot and the User Story Commit pages and allows you to remove components both in Git and in your sandboxes. If you want to delete a component in Git and also in the destination sandboxes, you should use this functionality in a user story. If you just want to delete the component in Git, you can use it in a Git snapshot.
When you select this operation, you can see the org credential and the metadata grid with the metadata components of the environment related to the org credential selected. If the component does not appear in the grid because it has already been deleted in the source org, then select a different org credential in the lookup field which corresponds to an org that still has the item to be deleted. The metadata grid will be reloaded with the metadata components of the new org credential:
If you cannot find a metadata component in the grid because it has already been deleted, you can click on Add Row, located at the bottom of the grid, to add a new selected row and type in both the metadata API name and the metadata type of the component. The text value in the cell of the new row must not be empty or include any blank spaces:
If you try to perform destructive changes on a component that does not exist in the master branch, a No Changes Git commit record will be created in relation to the user story. Copado allows you to modify the base branch from where the feature branch is generated:
- Click on the Advanced button, just next to the Commit Destructive Changes button.
- A new advanced section will be displayed on top of the metadata grid.
- As you can see, there is a lookup field named Select Base Branch which can be edited. The branch name value given in this field will be taken as a reference when creating the feature branch.
- Once the desired branch is selected, click on Apply.
If there are no branches displayed in this field, navigate to the Git Repository record in Copado, click on Manage Git Branches and then click on Refresh Metadata Index to refresh the branches.
What Happens When You Click on Destructive Changes?
The flow below shows the actions that will be executed by the user and those executed by Copado when the Destructive Changes operation is triggered:
Depending on whether you are committing from a user story or a Git snapshot, different things will happen. Let’s see what the results in each of these cases are:
- If you’re committing in a user story, the selected component will be deleted in the feature branch and then merged into the org's branch.
- If you are committing in a Git snapshot, the metadata will be deleted directly in the main branch.
Additionally, if the selected component represents a file, Copado will delete the entire file of the selected metadata. However, if the selected component is a nested component, Copado will update the file instead.
Let’s take a look at the changes when, for instance, a custom object is selected and committed using the Destructive Changes operation:
- The custom object file will be deleted.
- The translation file(s) will be deleted.
- The layout file(s) will be deleted.
- The workflow file(s) will be deleted.
- The sharing rule, matching rule, assignment rule, auto response rule and escalation rule file(s) will be deleted.
- The trigger file(s) will be deleted.
- The object permissions in profiles and permission sets will be deleted.
- The field permissions in profiles and permission sets will be deleted.
Once the destructive changes commit is completed, in the User Story selections you will find the deleted components and any other component that has been updated in case it was referencing the deleted component.
In the case above, you will find the custom object as well as the layout, sharing rules, workflow, triggers and any other object-specific components marked as Git Deletions in the User Story selections.
Additionally, profiles and permission sets that reference the object and its fields (as nested components) will appear as Git Upserts, since the reference to the object (OLS) and its fields (FLS) are removed from the profile and permission set XML files: