What is the best way to deploy profiles in Salesforce?
I have a system admin profile with access given to the objects that i have created in my sandbox. I have about 1000 fields across these objects. Eclipse suggests that we should not deploy profiles.
Also in production, there is a high possibility that Admins would have been given access to other object fields’ which are not available in my sandbox.
Say I have a sandbox
dev1and am working on it for application 1 after refreshing from production.
I have another sandbox
dev2and another group of devs are working on it for application 2 after refreshing from production.
Dev2goes live (to production) before
dev1, and in
dev2System Admin profile, I have added some fields based on the objects that are needed for application 2 and have deployed it to production..
Now, If I deploy
dev1to production (and if I have about some 1000 fields added in my
dev1sandbox and the access has been given to System Admin) :
How will I deploy this system admin profile with necessary field access to production? (Because if I overwrite the system admin profile, the field access that were already given for
dev2, application2 will be removed. How do I handle this??
I know we can achieve this using permission set for all other existing profiles. How to do this for System Admin profile?
The metadata API and the “change set” feature are not “destructive” by nature. Many people think that when you copy a profile, you are copying all of the permissions for that profile, including all object and field permissions. However, this simply isn’t true. While you do need to compare base profiles for a comparison of, for example, “API Enabled” or “Export Data”, objects and fields are enabled separately by default, which means that you can copy just a subset of all available permissions without worrying about a complete overwrite.
It is true that you should be wary about using profiles in the Eclipse IDE, and with good reason. The plugin is “smart” and tries to only deploy changes. This means that in order to deploy a change to a field level security item, you have to modify both the profile and the custom field in order for a change to occur. This is usually a huge hassle, and so you should probably avoid doing that.
Change sets, and the metadata toolkit, however, are perfect ways to copy just the permissions you want to copy. This is because the system will only change the settings relevant to the combination of profiles and fields/objects. The Metadata Toolkit gives you the flexibility of editing raw XML files, allowing you to copy only the information you want to.
Let’s take a look at using the Metadata Toolkit, since it’s fairly easy to use, and has reasonable documentation.
First, I create a package.xml file that has the following content:
<?xml version="1.0" encoding="UTF-8"?> <Package xmlns="http://soap.sforce.com/2006/04/metadata"> <types> <members>Lead.CurrentGenerators__c</members> <name>CustomField</name> </types> <types> <members>Admin</members> <name>Profile</name> </types> <version>29.0</version> </Package>
Here, I specifically request a single field and a single profile. The results of this export gives me:
<?xml version="1.0" encoding="UTF-8"?> <CustomObject xmlns="http://soap.sforce.com/2006/04/metadata"> <fields> <fullName>CurrentGenerators__c</fullName> <externalId>false</externalId> <label>Current Generator(s)</label> <length>100</length> <required>false</required> <trackFeedHistory>false</trackFeedHistory> <type>Text</type> <unique>false</unique> </fields> </CustomObject>
<?xml version="1.0" encoding="UTF-8"?> <Profile xmlns="http://soap.sforce.com/2006/04/metadata"> <fieldPermissions> <editable>true</editable> <field>Lead.CurrentGenerators__c</field> <readable>true</readable> </fieldPermissions> <userLicense>Salesforce</userLicense> </Profile>
If I change “editable” to false, and deploy this change to another organization with the same field (or, even if the field does not exist), then the only change that would occur is that the single field level security setting would change– all other fields, objects, and other permissions would remain intact.
This feature is often used to deploy security changes that are scoped out in a Sandbox. You can be as selective as you’d like to be, even down to just a single field’s permissions. In this manner, you can choose which permissions you’d like to deploy. Also, you could choose to manually edit the XML files before deployment to deploy different sets of field level security permissions within the same package. They do not need to be a fully rectangular matrix. For example, you could build a deployment like this:
Field 1 Field 2 Field 3 Profile 1 Edit - Read Profile 2 Read Edit - Profile 3 Edit Edit Edit
In this case, two field level security settings will not change (Profile 1’s Field 2 security, and Profile 2’s Field 3 security), while the other settings will be as specified. Hopefully this answer will help clear up the confusion of the other answers that have been posted to this question.
Only settings explicitly mentioned in a change set or metadata API xml file will be modified. One should not think of this as an “overwrite”, but instead a “selective edit.”