Force.com provide multilayered approach of data security. Each layer secure data using a different approach.
Object Level – security provided by Profiles and Permission-sets.
A profile in Force.com is a metadata used to group users with common data access requirements. It contains a set of permissions for every object defined in the Force.com organization. These permissions determine whether users belonging to the profile are authorized to read, create, edit, and delete records of each object. Also within the profile are rules determining access to individual fields of an object.
Fields can be hidden entirely or defined as read-only directly in the profile or in page layouts.
Permission sets contain the same permission-related metadata as profiles, but a user can be assigned to many of them at once. In contrast, a user is assigned to a single profile at a time. Permission sets are generally used to override profiles on an individual user basis.
Record-level security is layered on top of object-level security. It further restricts access to data based on the concept of record ownership. But it can never override object-level security. Organization-wide defaults define the default, most restrictive sharing behavior of each object, and sharing reasons create exceptions to this default behavior, granting access to specific groups of users.
- Object Permissions – ensures the requesting user is authorized by its profile to take desired action on the object.
- Field Permissions – You can restrict access to certain fields, even if a user has access to the object. The requesting user’s profile determine whether fields are included in the request are read-only or hidden.
- Org Wide Default(OWD) – OWD specify the default level of access users have to each others’ records. You use org-wide sharing settings to lock down your data to the most restrictive level, and then use the other record-level security and sharing tools to selectively give access to other users.
These defaults designate records of each object as private, public with Read and Write access, or public with read-only access.
- Role hierarchies – give access for users higher in the hierarchy to all records owned by users below them in the hierarchy. Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs.
- Sharing rules – are automatic exceptions to organization-wide defaults for particular groups of users, so they can get to records they don’t own or can’t normally see. Sharing rules, like role hierarchies, are only used to give additional users access to records. They can’t be stricter than your organization-wide default settings.
- Manual sharing allows owners of particular records to share them with other users. Although manual sharing isn’t automated like org-wide sharing settings, role hierarchies, or sharing rules, it can be useful in some situations, such as when a recruiter going on vacation needs to temporarily assign ownership of a job application to someone else.
4. Sharing reasons – Sharing reasons override the organization-wide defaults. The owner of the requested record is matched against a list of sharing reasons relevant to its group affiliation. If a sharing reason is found, access is granted. Groups are defined as simple lists of users and other groups or as a hierarchy, allowing permissions of subordinates to be inherited by their superiors.