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

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.

Updates
8/29/2019: The related work item reference number for this documentation enhancement has been changed from: W-2845639 to: W-6412239.

Is it Fixed?

AP0 AP3 AP4 AP5 AP6 AP7 AP8 AP9 AP10 AP11 AP12 AP13 AP14 AP15 AP16 AP17 AP18 AP19 AP20 AP21 AP22 AP24 AP25 AP26 AP27 AP28 CS1 CS2 CS4 CS5 CS6 CS7 CS8 CS9 CS10 CS109 CS108 CS107 CS106 CS105 CS102 CS101 CS100 CS115 CS119 CS110 CS117 CS114 CS113 CS112 CS111 CS11 CS116 CS123 CS122 CS121 CS126 CS127 CS129 CS128 CS125 CS124 CS137 CS138 CS133 CS132 CS14 CS148 CS142 CS159 CS152 CS151 CS15 CS162 CS16 CS169 CS165 CS160 CS173 CS17 CS174 CS18 CS189 CS194 CS192 CS193 CS190 CS191 CS199 CS197 CS19 CS198 CS196 CS195 CS20 CS201 CS203 CS21 CS22 CS23 CS24 CS25 CS26 CS27 CS28 CS29 CS31 CS32 CS33 CS34 CS35 CS36 CS37 CS40 CS41 CS42 CS43 CS44 CS45 CS46 CS47 CS49 CS50 CS52 CS53 CS57 CS58 CS59 CS60 CS61 CS62 CS63 CS64 CS65 CS66 CS67 CS68 CS69 CS70 CS72 CS73 CS74 CS75 CS76 CS77 CS78 CS79 CS80 CS81 CS84 CS86 CS87 CS88 CS89 CS90 CS91 CS92 CS94 CS95 CS96 CS97 CS98 CS999 CS99 EU16 EU17 EU18 EU19 EU25 EU26 EU27 EU28 EU29 EU30 EU31 EU32 EU33 EU34 EU35 EU36 EU37 EU38 EU39 EU40 EU41 EU42 EU43 EU45 IND1 IND2S IND3S IND5 IND7 IND9 NA104 NA107 NA109 NA100 NA101 NA103 NA102 NA105 NA119 NA116 NA110 NA118 NA112 NA111 NA115 NA114 NA113 NA117 NA125 NA124 NA122 NA120 NA126 NA127 NA123 NA129 NA121 NA128 NA138 NA134 NA133 NA136 NA135 NA132 NA131 NA130 NA137 NA139 NA140 NA142 NA141 NA149 NA146 NA147 NA148 NA154 NA158 NA159 NA153 NA151 NA155 NA152 NA150 NA156 NA172 NA174 NA171 NA173 NA196 NA202 NA21 NA46 NA49 NA52 NA61 NA62 NA64 NA65 NA66 NA68 NA69 NA70 NA71 NA72 NA73 NA74 NA75 NA76 NA77 NA80 NA81 NA82 NA83 NA84 NA85 NA86 NA87 NA88 NA89 NA90 NA91 NA92 NA93 NA94 NA95 NA96 NA97 NA98 NA99 UM1 UM2 UM3 UM4 UM5 UM6 UM7

Any unreleased services, features, statuses, or dates referenced in this or other public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make their purchase decisions based upon features that are currently available.