Mastering Salesforce Data Security: A Layered Approach
Introduction
In Salesforce, nothing is more important than the security of your data. The platform provides a powerful, layered security model that allows you to control access at every level, from the entire organization down to individual fields. Understanding these layers is the first step to building secure and compliant applications.
This guide breaks down the four main levels of data access.
Level 1: Organization-Wide Defaults (OWD)
This is the most restrictive layer of your security model. OWDs determine the baseline access level for all records of a specific object that a user does not own. The settings are:
- Private: Only the record owner and users above them in the role hierarchy can view and edit the record. This is the most secure setting.
- Public Read Only: All users can view the records, but only the owner and those above them in the hierarchy can edit them.
- Public Read/Write: All users can view and edit all records. Use this with caution.
- Controlled by Parent: The child record's visibility is determined by the visibility of its master (parent) record. This only applies to master-detail relationships.
Best Practice: Always start with the most restrictive setting (Private) and open up access as needed using the other layers.
Level 2: Role Hierarchy
The Role Hierarchy works in conjunction with your OWDs. It is a vertical sharing model that ensures managers always have access to the same data as their subordinates. A user in a higher role can always see and edit the records owned by users in roles directly below them.
Best Practice: Model your role hierarchy after your organization's data access needs, not just your org chart. A flat hierarchy is perfectly fine if there's no need for vertical data sharing.
Level 3: Sharing Rules
Sharing Rules are your tool for horizontal data sharing. They allow you to grant access to records for users who are not above the record owner in the role hierarchy. For example, you can create a rule that says "Share all Accounts in the 'West' region with the 'East' sales team."
There are two main types:
- Owner-based: Share records owned by a specific role or public group.
- Criteria-based: Share records that meet certain criteria (e.g.,
Industry = 'Healthcare').
Best Practice: Use public groups to define your sharing rule participants rather than individual roles. This makes maintenance much easier as users change roles.
Level 4: Profiles and Permission Sets
This is the final layer, controlling what users can do with the records they can see. This is where you define Object Permissions (Create, Read, Update, Delete) and Field-Level Security (which fields are visible or editable).
- Profiles: Every user has one Profile, which defines their baseline permissions.
- Permission Sets: These are used to grant additional permissions to specific users on top of their profile.
Best Practice: Build your profiles to be the "least privilege" baseline for a group of users, and then use Permission Sets to grant extra permissions. This "Permission Set-first" model is more flexible and scalable than creating dozens of different profiles.
By understanding how these four layers work together, you can design a security model that is both robust and easy to maintain.