Destructive Changes

Updated 1 month ago by Copado Solutions

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.

Please bear in mind that the Destructive Changes operation does not support Vlocity components.

When you select this operation, you can see the credential and the metadata grid with the metadata components of the environment related to the 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 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 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:

  1. Click on the Advanced button, just next to the Commit Destructive Changes button. 
  2. A new advanced section will be displayed on top of the metadata grid:
     
  3. 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. 
  4. 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.

Please note that this lookup field is case sensitive so make sure you enter branch names with the correct format (upper or lowercase).

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.

Destructive Changes on a Custom Object 

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:

Copado will not delete in the source org the components deleted with the destructive changes actions, they have to be manually deleted. On the other hand, they will be deleted in the destination org by Copado once the user story is deployed.

Destructive Changes on a Custom Field 

Now, let’s take a look at the changes when a custom field is selected and committed using the Destructive Changes operation. Since you can’t delete a custom field that’s referenced elsewhere, first you will have to manually check where the field is referenced and remove some of these references. To do this, follow the steps below:

  1. Go to SetupObject Manager → Select the object that contains the field you want to remove → Fields & Relationships → Select the custom field you want to remove and click on Where is this used? 

  1. Here you will be able to see all the field references. You will have to delete all the references, except for objects, layouts, profiles, permission sets, report types, reports, record types and list views since they are automatically updated when the field is deleted: 

  1. After you have manually deleted all the references associated with the custom field, you can proceed to commit it with the Destructive Changes operation:
  • The custom field will be deleted from the object and removed from the associated page layouts, reports, record types, and list views.
  • The field permissions in profiles and permission sets will be deleted.
  • You will find the custom field marked as Git Deletions in the User Story selections, and any profiles and permission sets that reference the field (as nested components) will appear as Git Upserts:

Field values should be archived before a field is deleted since all field data is deleted. Deleted fields and their data are stored for a maximum of 15 days, during which they can be undeleted or permanently erased.


How did we do?