Home > Salesforce.com, security > How Stuff Works : Roles and Profiles

How Stuff Works : Roles and Profiles

If I had a penny for each time I’ve seen someone trip over the difference between Roles and Profiles, I’d be a millionaire. Not really, but I’d prolly have enough to pay for a month’s coffee. And I don’t like my coffee cheap. So here goes.

Roles and Profiles are different for want of a better word. Complementary even.

The Organisation Wide Default (OWD) is the foundation, which decides whether default record sharing for the object is Private / Public Read Only or Public Read Write. This is the most restrictive data setting.

Roles have to do with data visibility, where the data you can see is dependant on your position in the Role Hierarchy and the Sharing Settings.

When the (OWD) is Private, Sharing Rules become available to open up the OWD data restrictions to groups of users or roles and subordinates. These can either be ownership based or criteria based(with some limitations)

Another way to share data is through Apex sharing where you can programmatically insert share records based on custom logic too complex to encapsulate as Criteria Based Sharing Rules.  Then of course, there is good old Manual Sharing!

Profiles control what you can do with the data that is visible to you, certain administrative permissions and of course which objects in the schema you have access to and the level of access (CRUD).  Field Level security, for example, lets you control at a Profile Level which fields are visible or read only to certain profiles.

The View All Data and Modify All Data permissions on the Profile are exceptions because they bestow ‘SuperCow Powers’ on the users with that Profile. Hence why they are normally granted only to Full System Admins. (There are also per sObject View All and Modify All Permissions, which can be leveraged to grant certain Profiles complete access to certain sObjects)

Additionally Profiles also control which Apex Classes and Visualforce pages the user has access to.

Permissions Sets are a way to provision profile permissions in a modular fashion so you can group a bunch of related (Profile) permissions. They supplement the permissions already granted to a user by virtue of their user profile.

In summary, the Security model is a little bit like an onion – comprising of layers that work together to constitute the whole. As you peel away the layers, you begin to understand the part each one has to play in ensuring that Users can only see and do what you will for them as an administrator !

Practise What You Preach !

To put into perspective all that we’ve discussed, let’s attempt to understand the things that need to be in place for a User to see an Account record. For starters, the Profile needs to have, as a minimum, Read access on the Account sObject. Now to view the data, the User needs either to be the Owner of the record, above the Owner in a Role Hierarchy, or granted access via Sharing to a Public Group or Roles and Subordinates.

It therefore follows that say if  you’re not able to view an sObject tab, it will be down to your Profile, which is probably missing Read Access. If however, you can see certain records, but not others, it is then down to your Role and the Sharing Settings.

Advertisements
Categories: Salesforce.com, security
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: