Destructive Changes

Updated 2 months 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 the Git Snapshot record.

When you select this operation, you will see the org credential and the metadata grid displaying the org credential’s metadata components. 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 that corresponds to an Org that still has the item to be deleted. The metadata grid will be reloaded with the new org credential’s metadata components.

If you cannot find a metadata component in the grid because it was already deleted, you can click on the Add Row button, located at the bottom of the screen, to add a new selected row and type in both the metadata API name of the component and the metadata type. The cell's text value of the new row must not be empty or include blank spaces.

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 was updated in case it was referencing the deleted component. In the case above, you will find the custom object as well as its 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 when the user story is deployed.


How did we do?