13 May 2013

Why 'Standard' Profile Permissions Can't Be Changed

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.


  1. 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:
    -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.

    1. Really good points! I've shared internally. Thanks for the feedback!

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

    1. Hi Candy,

      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.

  3. Getting below error while updating any profile in salesforce. Please help.

    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

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