[SalesForce] Deployment Failed – You may not modify the permission Reserved for Future Use while editing a Standard 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:

objects/Lead.object

<?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>

profiles/Admin.profile

<?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.

TL;DR version

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."

Same issue showed up on one of our Sandboxes just today. We worked around it by manually changing the Admin.Profile XML, forcing the permission to be set to False as the first userPermission in the list.

<userPermissions>
    <enabled>false</enabled>
    <name>CreateWorkBadgeDefinition</name>
</userPermissions>

This allowed the build to be successful, so we reverted the XML to the original version. To try this you need to use API v29 or higher.