I saw this question on the Salesforce StackExchange and thought it would be good to clarify why 'standard' profiles are immutable:
"Why does salesforce not allow us to change the permissions of standard profiles to standard objects? I know the workaround to use is to clone that standard profile into a custom one, but it seems like a pretty random limitation to impose."Profiles are an extension of licensing in salesforce.com. Licenses enforce access and define the maximum allowed permissions for a user. Profiles are actually the glue that connects licenses and users together. Every time you create a user, you specify a license and then assign a profile from a picklist that only includes profiles that share the same license. Under the covers, a profile is actually the middle object between user and license.
Every time a license is added to an org, we automatically create one or more 'standard' profiles with immutable user and object permissions. You'll notice that other things on 'standard' profiles can be changed like assigned apps, tab settings, and record types.
A best practice for customers with the ability to create 'custom' profiles is to use these 'standard' profiles as templates in order to clone and create their own. In some editions where custom profiles are not allowed, assigning 'standard' profiles is the only way to provide access for users. Check out this blog posting to understand more about this best practice.
The 'standard' profiles are also considered managed just as components in an appexchange package are managed by an ISV (Independent Software Vendor). 'Custom' profiles, similar to any other customization in your org that you create, are considered not managed and have special rules that protect them from being changed during a release cycle.
From release to release, we may add an object or a new set of functionality that we want to license differently. A full CRM salesforce license may get access automatically to some new sales feature whereas the platform license may not.
When we upgrade our code during the release, we may allow and enable access to these objects and new features through object and user permissions on 'standard' profiles. But you'll notice that we almost never change your 'custom' profiles. This enables easier transition through our release process since you can choose whether to include access to these new objects or new features in your own 'custom' profiles.
Another reason why we will enable certain objects or user permissions in the 'standard' profiles is that they are used in group and professional editions where there is no ability to clone or customize a profile and you wouldn't get access to new features or objects unless we enabled permissions automatically on our 'standard' profiles.
There are many reasons why 'standard' profiles are immutable and I hope this blog posting helps illuminate why.
Good information as usual (slowly making it through all your posts). I would like to point out one implication that we ran into when we turned on Chatter Plus. The "standard" profile that was created by support actually contained a random grouping of custom objects. I would really recommend having NO object cred on the Chatter Plus or Force.com one app licenses where the license is supposed to be limited to only certain object and/or a certain number of objects. This was problematic for our org because:ReplyDelete
-The custom objects added to the standard profile added up to 14 objects, leaving us out of compliance on that profile (license type is limited to 10) and no way to fix it.
-Two of the objects had a dependency to Case (which isn't included at all in Chatter Plus), and therefore when we Cloned it, we couldn't make any changes to that profile until we fixed that dependency. Since you can't edit two object CREDs at once in the Enhanced Profile editor, had to revert back to the old version, remove the objects and then switch back. This took quite awhile to figure out.
In general, we're moving to a model where the profile itself only has CRED on standard objects and all custom object cred is handled via permission sets, which really is a better way to do it and setting up those standard profiles with no custom object cred really makes the most sense as it forces you to go to the custom, which I believe is the goal anyway.
Really good points! I've shared internally. Thanks for the feedback!Delete
Hi - in our org, we would like to restrict group creation from any other users except System Administrator. But when users with the "Chatter User" profile are created by invitation - they are by default given the access to create new groups. Is there a way to go around this without having to create a custom profile?ReplyDelete
Sorry for the delayed response. Unfortunately, we don't allow editing of standard profiles (currently). That may change in the future. Creating a custom profile is really a best practice. The only standard profile I ever recommend assigning is the System Administrator. Otherwise, the first thing I do with all profiles in a new org is create a custom clone of it so that I have full control of the permissions.
Getting below error while updating any profile in salesforce. Please help.ReplyDelete
Error: Invalid Data.
Review all error messages below to correct your data.
• Permission Create Invoices depends on permission(s): Read Orders
• Permission Delete Invoices depends on permission(s): Read Orders
• Permission Edit Invoices depends on permission(s): Read Orders
• Permission Read Invoices depends on permission(s): Read Orders
Hope you solved this by now but the short answer is that objects have dependencies between them and you must fulfill those dependencies before saving the profile. IN this case, you can't change the permissions because Read Orders is required.Delete
This is an unfortunately common issue especially after turning on a new feature in SF or installing a package. In terms of how to fix it, you have to go into the OLD profile setup page (toggle this setting from User Interface in setup). That allows you to change multiple object permissions at once and then save. If you are using the new interface, it's impossible to fix as you can only set one object's permissions at a time.Delete
Not entirely impossible: http://www.salesforcehacker.com/2013/01/mass-edit-profiles-using-enhanced.html?m=1Delete
The issue where you have dependent permissions can't be solved with enhanced profile list views. They allow you to change many of the same permissions across profiles. What the issue described above involves is actually change many different OBJECT permissions at the same time on the same profile. In the Enhanced Profile List Views, each object permission is its own separate column requiring its own separate save. Oftentimes it is multiple sets of non-interrelated dependencies as well (e.g. 10 objects affected but really the issue is 4 specific object permissions that need to be removed simultaneously). Enhanced Profile List Views are also basically unusable in larger orgs as all you see is the "Search to refine criteria" error. Much faster and easier to go back to the old editor.ReplyDelete