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
- To extract Apex class accesses > Extract the relevant Apex classes
- To extract Visualforce pages accesses > Extract the relevant Visualforce pages
This can be easily done by updating the content of your package.xml file.
e.g. To extract the Admin profile along with object permissions for Account and Contact and a few custom Apex classes and Visualforce pages, you would need to following in your package.xml:
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:
The main target that calls the remove step and the deploy step
The target that removes all unwanted objects from the deploy metadata.
It calls the RemoveFromPackage target for each unwanted object.
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)
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.