Salesforce How To: Extract and Deploy FULL profiles with ANT

1 – Introduction

Salesforce profiles tend to change quite often and regularly need to be deployed to multiple Salesforce orgs (e.g. when a new field is added). This can easily be done with the Force.com migration tool (a set of ANT methods supplied by Salesforce to extract and deploy metadata).

However, extracting profile comes with a small limitation. When you extract a profile on its own, it only contains a fraction of the information normally available in a profile (mainly user permissions). To get more information extracted into a profile, you need to also extract the relevant objects along with the profile itself. For instance, if you want to extract the Admin profile including object and field permissions for the Contact object, you need to extract both the Admin profile and the Contact object together.

It’s all very well but more often than not, you probably just want to deploy profiles and not all the related objects. You can do that automatically with ANT, in this article, I’m going to show you how to.

2 – Prerequisites

In this article, I will assume that you are already familiar with ANT and the Force.com Migration Tool.

The Force.com migration tool is a set of ANT methods to extract and deploy meta data between Salesforce orgs. It’s a very powerful tool that offers much more flexibility that change sets.Info about it can be found here:Using Force.com Migration Tool

3 – Extracting profiles and related objects

When extracting a profile on its own, the extracted metadata file contains only a limited set of information (mainly user permissions).

For a profile to contain a more complete set information, you need to also extract related objects along with the profile itself, e.g.

To extract object and field permissions > Extract the relevant objects

When extracting with the above package.xml, you’ll see that your Admin.profile metadata file will be substantially larger than before, containing information such as object and field permissions, apex class and visualforce page accesses.

Now a “side effect” is that we’ve also extracted metadata files for the related objects, apex classes and visualforce pages. In the next step, we’ll see how we can remove these automatically.

4 – Removing Unwanted Metadata Files from the Deployment

In the previous step, we’ve extracted additional metadata (objects, apex classes and visualforce pages) to get more information into our profile.

We might not actually want to deploy these files, so all we need to do is remove them before we deploy. To do this, we can create an ANT step that we call just before deploying. Since we already use ANT to deploy the metadata, we can add this step to the same build.xml file.

The build.xml file would contain 3 targets:

Deploy_TEST
The main target that calls the remove step and the deploy step

RemoveObjectListFromPackage
The target that removes all unwanted objects from the deploy metadata.
It calls the RemoveFromPackage target for each unwanted object.

RemoveFromPackage
Target that removes a specified object from the deploy metadata (files + entry in package.xml)

So the build.xml could look something like this (only removing objects Account and Contact)

Note that in the example above, we only removed the unwanted objects Account and Contact. If we wanted to also remove Apex classes or Visualforce pages from the deployed metadata, we would do it the same way by creating new targets like RemoveObjectListFromPackage that would remove Apex classes or Visualforce pages rather than objects.

5 – Conclusion

With minimum effort, you can extract more information from profiles and build a set of ANT targets to remove unwanted metadata before deploying. That way you can deploy profiles containing much more relevant information and avoid having to manually update all your environments.