Salesforce.com security model

This is an attempt to help my audience to understand the very basics of the Salesforce.com security model. A clear understanding of the security model is a must for all developers and administrators. At the very least, one should know the types of security and the ways security is enabled/disabled. 

Salesforce.com security is defined at multiple levels. These levels help to share or hide the details with the users. Following are the broad classification of Salesforce.com security model 

1. Object level security
2. Field level security 
3. Record level security

Object Level Security

As the name suggests this level of security is at the object level. You can specify permissions like create, read, update and delete on a particular object(standard and custom). Along with these permissions you can also specify "View All" and "Modify All" permissions. These permissions are often called CRUD permissions. 

This is one of the basic and most important security setting. In Salesforce you specify object level security by using profiles. A profile is a collection of permission and settings, which is used to control access to a particular set of users. For example - you can create a custom profiles for internal users, with only read access, similarly another profile for users who can read and write. 

Use the object level security to provide the basic CRUD access to the users.

Permission	Description	Respects or Overrides Sharing?
Read	Users can only view records of this type.	Respects sharing
Create	Users can read and create records.	Respects sharing
Edit	Users can read and update records.	Respects sharing
Delete	Users can read, edit, and delete records.	Respects sharing
View All	Users can view all records associated with this object, regardless of sharing settings.	Overrides sharing
Modify All	Users can read, edit, delete, transfer, and approve all records associated with this object, regardless of sharing settings. Note “Modify All” on documents allows access to all shared and public folders, but not the ability to edit folder properties or create new folders. To edit folder properties and create new folders, users must have the “Manage Public Documents” permission.	Overrides sharing

I have taken the above table from one of the Saleforce.com help sites. I find this very useful for anyone just starting to learn Salesforce. The third column, represents exceptions to the normal settings. Sharing settings are used to open the default permissions based on some criteria's, for example, give view all to the users in VP role. The sharing settings is a different monster which I will address in a later post. For now, I will stick to the basic security settings to keep this simple. 

Field Level Security
This layer helps the administrator to restrict the access to a specific field to users. These setting will apply to Reports, List Views, Detail and Edit pages, imported data etc. 

Setting Up Field Level Security
To set up field level security (on the edit and detail page), you will need to use a combination of field level security setting and page layout settings. By design the most restrictive setting will trump. For example -  if a field is required in the page layout and read-only in the field-level security settings, the field-level security overrides the page layout and the field will be read-only for the user 
There are two ways to set the field level security

1. Use the field level security section of a profile (Setup > Profile > Objects and Tabs > Field Permissions). This way you can set up field level security for multiple fields in on a single profile

Field Permissions Settings

2. Select the field (for which you want to set permissions) through objects, click on set field level security and make it visible/read only to all the available profiles. 

Record Level Security
This layer enables to you restrict access on records. This layer is very powerful and requires good understanding of the following concepts 

• Sharing Rules/Teams
• Role hierarchy
• Sharing Model/Org Wide Default (OWD)
• Record Ownership's and profiles

I will briefly cover these concepts to give you a better understanding of the model 

Record Ownership's and profiles

This is a basic concept but an important one. The profiles controls the basic access to an object. Without a read access to an object through a profile, you will not be able to see any records related to that object. Profile is the most restricted setting. 

Sharing Model/Org Wide Default (OWD)

The OWD defines the default permissions that users have to view and edit information within Salesforce.com. Each object can have the following sharing model

1. Private

2. Public Read Only

3. Public Read/Write

It is always advisable to start with the most restrictive access and then start working your way up. One should set the OWD first and then plan the other security settings. 

Role hierarchy

The roles enables users to view their own records (obviously :-) ) along with the records of the users under them in the role hierarchy. It also allows a user to edit, change record owner ship of the records owned by users below them.

Sharing Rules/Teams

Sharing rules extend the sharing access so that all data created by users in a certain role or public group is shared with users in another role or public group. One thing to keep in mind, sharing rules are exceptions to OWD and they cannot be stricter than OWD.

For example - lets say there are 2 teams, finance and sales. They want to track customer records for different purposes, however, the records are currently visible to Finance team. You can use a sharing rule to say that all the records owned by Finance are visible to sales team. 

Criteria based sharing rules allows sharing records based on field values in a record. 

Users can manually add sharing rules to grant other users access to records. 

Now, if you consider the record based sharing, the access level opens up as you move from profiles to OWD to Role hierarchy to Sharing rules. I specially like this funnel representation of the access level. I think it may be useful to you guys also, to remember the access level

Record based sharing 

Conclusion
The security model for an organization depends completely on its needs. It may or may not use all the above mentioned settings, however, these settings when combined together provide a solid security implementation. It is always advisable to document your security model before building it, because there are a lot of moving parts which change during a life cycle of a project. If not managed properly the security of the system may be compromised and it can become unmanageable easily. 

I hope you guys like this post!! If you do please share it with others. Keep posting your comments and feedback. Thanks