standard profiles and standard objects

Question

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.

Answer 1

I am the product manager for profiles and permission sets at salesforce.com.

This is an interesting question and well worth asking. techtrekker is pretty close with his/her answer.

Profiles are an extension of licensing in salesforce.com. You'll notice that it's the glue that holds licensing and users together. Every time you create a user, you specify a license and then you can assign a profile based on a picklist restricted only to those profiles that share the same license. Under the covers, profile is actually the middle object between user and license.

Each license consists of any number of different permissions in it, but primarily user and object permissions which are the two immutable settings in a standard profile.

Every time we provision a license into 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. It's a best practice that customers with the ability to create 'custom' profiles will use these 'standard' profiles as templates to clone and create their own; however, we know that often customers will take the path of least resistance and assign 'standard' profiles instead. In some editions where custom profiles are not allowed, assigning 'standard' profiles are the only way to provide access for users. I crated a posting on my salesforcehacker blog to explain this best practice: http://www.salesforcehacker.com/2013/04/use-custom-profiles-where-possible.html.

The 'standard' profiles are considered salesforce.com intellectual property just as managed components in an appexchange package are the intellectual property of the ISV (independent software vendor). 'Custom' profiles, similar to any other customization in your org that you create are considered your own intellectual property and have special rules that protect it from being changed during our 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 reserve the option to automatically allow and enable access to these objects and new features through object and user permissions on 'standard' profiles. But you'll notice that we rarely, if ever, touch 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.

I hope this helps explain why we make 'standard' profiles immutable to some degree. Definitely check out the salesforcehacker blog for more tips and tricks working with permissions in salesforce.com. Thanks!

Answer 2

1) Historical Baggage and 2) Non-Standard Features.

Both standard objects and profiles were created before customization was possible. By the time customizable objects and profiles came out a lot of them had features beyond what the new customizable objects and profiles allow, i.e. Opportunity Stages. I think Salesforce would like to migrate all of their standard stuff over to the customizable framework, but decided it wasn't worth the effort and that asking people to clone stuff was a lot cheaper.

Disclaimer I previously worked at Salesforce, but not in Product Management, so this is primarily conjecture.