Delete a Sharing Rule via Destructive Changes

Recently a colleague of mine had difficulties with deleting a Sharing Rule with our CI/CD solution. I tried helping him and saw that it’s not that easy to do it, so I decided to document the process in this blog post.

How are we going to delete a Sharing Rule?

We are going to use destructive changes to delete it. In particular, we will use the destructiveChangesPre.xml file.

When a destructiveChangesPre.xml file is part of a deployment package, it will instruct Salesforce to delete all of the components listed in the file before deploying the actual metadata within the package. Keep in mind that not everything can be deleted with this file - e.g. components that are referenced elsewhere within the system will not be deleted and will usually cause the deployment to fail. In those scenarios the alternative approach is to use a destructiveChangesPost.xml file, as the components in this file will be deleted after the main package is deployed, so it will give you a chance to remove the references to the metadata that you are trying to delete, before actually deleting them.

Why is deleting Sharing Rules so difficult?

Deleting Sharing Rules can be a bit tricky as there are 3 things that you need to identify before actually listing the Sharing Rule in the destructiveChangesPre.xml file. These are:

1. Sharing Rule Developer Name
2. Sharing Rule Object
3. Sharing Rule Type

Sharing Rule Developer Name and Object should be pretty straightforward to identify, as you can see that information directly from the Salesforce Setup by going to the Sharing Settings.

NOTE: If you are unsure how to get the Developer Name of a Sharing Rule, go to Salesforce Setup > Sharing Settings > Click Edit on the Sharing Rule that you want to identify and the Developer Name will be in the Rule Name field.

So let’s pretend that we know the Developer Name and Object already and that we want to delete two rules on the Account object named Sharing_Rule_1 and Sharing_Rule_2. Now we need to identify their types.

How to identify the type of a Sharing Rule?

The easiest way (for me) to identify a Sharing Rule Type is to search for the rule by its Developer Name within the Sharing Rule file of the object it belongs to. In this case, because we know that the rules belong to the Account object, the file that we need to search through is called Account.sharingRules-meta.xml. So let’s search for our sharing rules and try to identify their types.

Owner Based Sharing Rule

First, we search for Sharing_Rule_1 and we find the following result:

Looking at the picture above you will see that the surrounding tag (the first and the last line) is called sharingOwnerRules. This is a tell-tale sign that this is, indeed, an Owner-based sharing rule (SharingOwnerRule).

Criteria Based Sharing Rule

Next, we search for the second rule called Sharing_Rule_2 and see the following:

Using the same approach as before, we can now clearly see that this is a Criteria-based sharing rule (SharingCriteriaRule).

How to add the Sharing Rules to Destructive Changes?

Now that we have all the information we need, we can piece together the destructiveChangesPre.xml file to look as following:

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  <types>
    <members>Account.Sharing_Rule_1</members>
    <name>SharingOwnerRule</name>
  </types>
  <types>
    <members>Account.Sharing_Rule_2</members>
    <name>SharingCriteriaRule</name>
  </types>
  <version>51.0</version>
</Package>

Notice that each rule is listed based on its type (SharingOwnerRule vs SharingCriteriaRule). As well, each rule has to be prefixed by the name of the object that they belong to - in this case, that is the Account object (for custom objects don’t forget to add the __c suffix).

Final words

This is all you need to know to delete a Sharing Rule via Destructive Changes, which are nowadays usually used together with some kind of a CI/CD implementation. I hope this blog post was helpful.

You can read more on the Sharing Rules here.

Things to keep in mind

Some combinations of sharing rule and sharing model changes will not be deployed properly in a single transaction, so sometimes manual post-deployment steps or multiple subsequent deployments will be required.

Please see below in which scenarios the issues may happen. These snippets are taken from this article:

Simultaneously updating the sharingModel field for an object and adding a new owner-based sharing rule isn’t supported in Metadata API. You can add an owner-based sharing rule when the org-wide default is public, and subsequently update the sharingModel, which would result in a single sharing recalculation. You can deploy a criteria-based or guest user sharing rule and changes to the sharingModel field together using the Metadata API.

Simultaneously inserting a custom object, updating the sharingModel field for an object, and adding a new owner-based sharing rule isn’t supported. Instead, three separate deployments are required. First, deploy the custom object, then deploy the updated sharingModel for the object, and then deploy the new owner-based sharing rule. You can update the sharingModel field and add a criteria-based or guest user sharing rule in one deployment.

Written on July 12, 2021

Share this