Known Issues · No Fix

Doc Fix: Detail how object level CRUD access is set when a new profile is created or deployed via Change Set

Custom Objects , Metadata , Change Sets

Last updated 27 days ago ·Reference W-6412239 ·Reported By 4 users

No Fix

Summary
This documentation fix or work item was created to more clearly explain expected default behavior for how object level (CRUD) access is set on deploy of new profiles via change sets.

Existing documentation: Special Behavior in Deployments
https://help.salesforce.com/articleView?id=deploy_special_behavior.htm&type=5

States, "If a package includes a profile with a name that doesn’t exist in the target org, a new profile is created with that name. If the deployed profile doesn’t specify any permissions or settings, the resulting profile consists of all the permissions and settings in the Standard Profile."

The 'Standard Profile' referenced in the documentation is referring to the standard profile from which a custom profile was cloned.

Typically, a standard profile is created for each user license type provisioned in an org. For example, the standard profiles that are associated with community user licenses are outlined in 'License Detail' section of the documentation here:
https://help.salesforce.com/articleView?id=users_license_types_communities.htm&type=5

So if you were to create a custom profile for the 'Customer Community' user license type as an example, you would do so by cloning the existing standard profile, 'Customer Community User.'

Object level access specified in the custom profile is only included in the change set if the corresponding object component is also included in the change set.

It's not possible to include standard objects as change set components or applicable to always include all existing custom objects as change set components.

This effectively means that any new custom profile created in the target org via a change set deployment will inherit all standard and custom object (it it's not included in the change set) CRUD permissions that are set for the standard, 'Customer Community User' Profile in the target org.

Repro
1. In a source environment create a new custom profile and set object CRUD level access.

2. Include the new profile and custom object (Custom__c) in an outbound change set.

3. Deploy the change set in the source environment.


Actual Results: The newly deployed profile's object level or CRUD access is only set for the Custom__c object.

All standard object and other custom objects that were not included as change set components have their object level permissions set to what's specified in the associated standard profile in the target org.

In reviewing the Source for the profile in the target org's change set you'll see that only the included object permissions are specified in the change set XML for the profile:

<objectPermissions>
<allowCreate>false</allowCreate>
<allowDelete>false</allowDelete>
<allowEdit>false</allowEdit>
<allowRead>false</allowRead>
<modifyAllRecords>false</modifyAllRecords>
<object>Custom__c</object>
<viewAllRecords>false</viewAllRecords>
</objectPermissions>

This means that your newly deployed profile from the source org may be set with more permissive object level access in the target org via the object permissions set in the related standard profile.

Expected Results: This behavior would be very clearly documented to avoid any unexpected issues arising from including profiles in change sets.

Workaround
In the target organization, update or adjust object level permissions to match the source organization for newly deployed or created profiles post deployment.

Alternatively, use a metadata deployment tool such as the Force.com Migration Tool that includes the profiles object level permissions XML for all standard and custom objects.