What is the best way to deploy profiles in Salesforce? (especially system admin)

Question

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 someother object's fields' which are not available in my sandbox.

To detail it :-

Say I have a sandbox dev1 and am working on it for application 1 after refreshing from production.

I have another sandbox dev2 and another group of devs are working on it for application 2 after refreshing from production.

Dev2 goes live (to production) before dev1, and in dev2 system 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 dev1 to production (and If I have about some 1000 fields added in my dev1 sandbox 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 fro 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 administrator profile?

Answer 1

Profiles are the only piece of metadata for which I advocate making changes by hand. It can be tons of clicking, but the metadata API is far too "all or nothing" for profile changes to easily keep them in synch, at least in my experience. Attempting to deploy Profiles automagically carries the added risk that comes from the fact that in dev sandboxes, it's frequently necessary to mess around with privileges when doing profile-related stuff, and it's easy to accidentally deploy a security change one did not intend.

Using diffs against profiles is basically impossible for anything but the most trivial of changes - profiles get lots of stuff added in different positions, and your source profiles will likely be so out of synch with the destinations that a diff is not practical.

I've taken to doing deploys with Ant, then a long "run list" of sys admin manual changes, which are usually mostly profile clicks that have been compiled by the developers. Then the admin makes the changes, and tests them by impersonating the various modified profiles.

I suppose permission sets could ease part of the pain with this, but I haven't yet rolled them into my methodology so can't really comment.

Answer 2

The Metadata API is the fullest footprint of settings - packaging and change sets both make assumptions on how to handle particular cases that may not be desirable. I definitely recommend making changes through the Force.com IDE or ANT. Also, while ultimately there will be some cases where you will have to make manual changes (e.g. standard apps like sales or call center are not supported in the Profile metadata type in the Metadata API and therefore must be made manually), you can at least reduce the number of manual changes you need to make.

Keep in mind, profiles can be big - for each object in your org, there are six bits of permissions, each field of each object there are two bits of permissions, each visualforce page or apex class is a bit, and then there are approximately 150 user permission bits to manage on top of it. And that's without settings like record types or layouts - all in all, there can be well over a million configurations to capture in a larger org so you might as well make it easier by automating where you can.

Answer 3

I have one other suggestion / workaround which worked well for me when faced with the same problem you have: use permission sets.

Profiles have their well-known drawbacks and permissions sets are perfect for packaging authorisation for new applications. Say you are developing a new application with it's own objects, pages, classes and tabs. Create a new permission set which you then deploy. You can then assign this to:

1. Individual users manually
2. Multiple users via the Data Loader OR
3. Multiple users via The Permissioner app

Answer 4

I would suggest you can compare the metadata files for profiles using file comparator tools like diff doff or exam diff and then come to conclusion that this are the major changes that are essential.

Then may be you can modify metadata according to your need and then use ANT to push the changes .

ANT provides the flexibility of changing the metadata also you can mock run in the sandbox before doing final deployment

Answer 5

This is an excellent question in need of a solution. In theory you can compare the .profile files between orgs but here's what I've learned:

1. Make sure you have 2 projects (PROD and SandBox) which both have all meta data contained. I noticed any objects missing in your project do not appear in the profile metadata file!
2. You have to sort and normalize the .profile xml in order to compare it with text-based diff (non-XML) tools. One way would be to write an XSL which does this (see sample below).

You can then compare the PROD and Sandbox .profile files, merge and (in theory) deploy.

Sample XSL

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns="http://soap.sforce.com/2006/04/metadata"
    version="1.0">

    <xsl:output method="xml" indent="yes" encoding="utf-8" omit-xml-declaration="yes" />

    <xsl:template match="/Profile">
    <Profile>

    <xsl:for-each select="classAccesses">
        <xsl:sort select="apexClass"/>
        <classAccesses><xsl:copy-of select="apexClass"/><xsl:copy-of select="enabled"/></classAccesses>
    </xsl:for-each>

    <!-- Another for-each for each object type:
         classAccesses
         fieldPermissions
         layoutAssignments
         objectPermissions
         pageAccesses
         tabVisibilities
         userLicense
     -->

    <xsl:for-each select="userLicense">
        <xsl:copy-of select="."/>
    </xsl:for-each> 

</Profile>
</xsl:template>

</xsl:stylesheet>

This XSL still needs some work (obviously) in order to allow you to compare each object type.

Answer 6

Diff'ing profiles via their metadata XML is time consuming, but I disagree with previous answers that it is useless or impossible.

The first step to happiness is to push all non-profile changes so that the two orgs are synchronized.

Next, we must ensure that we are comparing apples to apples. To do this, we'll need to ensure that we are using the same package.xml when pulling the profiles (either through the Eclipse IDE or ANT). Now we can readily compare the files.

Additional suggestions:

1. If there are many changes to the profile involving non-conflicting SObjects (e.g. we are only worried about additional field access granted on Accounts, Contacts, and Opportunities), consider splitting out the package.xml into "stuff we're happy to overwrite" and "stuff that we need to carefully merge". This will allow you to focus your attention where it is needed. With one deployment being easy, while the second requires the manual diff'ing.

2. If you need to merge profiles, you can do this using a combination of cloning the existing profile, deploying your new profile on top of the cloned profile, then (optionally) redeploying the original profile on top of the cloned profile. Note, you'll need to manually change file names to accomplish this, but it works if the two profiles are generally distinct.