Unlocking Salesforce Permissions: From Object Security to Apex Sharing
Introduction
When working with Salesforce, to understand its permission model is crucial to ensure data integrity, protect confidential information, and provide the right access to the right users. Regardless of whether you are an administrator, developer, or architect, permission management allows you to create scalable and secure applications on the Salesforce platform.
In this article, I would like to suggest you consider the following types of permissions:
- Object-Level Security
- Field-Level Security
- Record-Level Security
- Sharing Sets
- Apex Sharing using __share Objects
- Profiles vs. Permission Sets
1. Object-Level Security
Object-level security determines whether a user can read, create, edit, or delete records of a particular object. This is often controlled using Profiles or Permission Sets.
In order to configure permissions for an object in Setup, follow this path:
Profiles → Object Settings (of the Apps section) → [Object] → Object Permissions
- Permission Sets → Object Settings (of the Apps section) → [Object] → Object Permissions
In order to provide the following standard permissions for an object:
- Read
- Create
- Edit
- Delete
- View All
- Modify All
2. Field-Level Security
Field-level security defines field-level access to a record. A user can see a record, but only some of its fields, depending on their permissions.
In order to set up field-level access in Setup, follow this path:
- Profiles → Object Settings (of the Apps section) → [Object] → Field Permissions
- Permission sets → Object Settings → [Object] → Field Permissions
Permissions for fields can be set to:
- Visible (Edit Access): The field is displayed in the user interface (UI) and is accessible via API
- Read-only: A user can view, but not edit a field
- Hidden: The field is completely invisible to the user
Use field-level security when you need to display confidential information contained in the fields only for certain roles, such as disclosing salary information only to the HR department.
3. Record-level security
Record-level security (also known as sharing) determines which individual records in an object a user can access. Even if users can read the object, they may not see all the records — this level of security is important for multiuser environments.
Salesforce offers its users several mechanisms for sharing records:
a) Organization-Wide Defaults (OWD) defines the basic record access level:
- Private. The user sees only his own records, the ones he owns. For example, If OWD for Opportunities are set to Private, then the sales manager sees only his own deals, but not the deals of other colleagues.
- Public Read Only. Users can see all the records, but they can only edit their own. For example, all managers can see each other's deals (for example, to study), but they can only edit their own.
- Public Read/Write. All users can see and edit all records. Example: in a small company, everyone works together and can edit any opportunities.
b) Role Hierarchies
Managers automatically inherit access to records belonging to their subordinates.
c) Sharing Rules
It is used to grant access to groups of users based on record criteria or ownership.
There are the following types of rules:
- Ownership-based → share records that belong to a specific role/group.
- Criteria-based → share records that meet certain conditions.
Examples:
Ownership-based: All the Opportunities owned by users in the Sales East role are automatically shared with users in the Sales West role.
Criteria-based: All Opportunities with stage = Closed Won are automatically shared with the Finance team so they can issue invoices.
d) Manual Sharing
Users can manually grant access to individual records they own to other users.
For example, Peter (Sales Representative) has a deal with a client. But Peter is going on vacation for the whole next week, and he needs to transfer this client to his colleague Kate for a while to keep in touch with the client. Peter manually shares this deal with Kate so that she can edit the record.
4. Sharing Sets
Sharing Sets are a declarative method that allows users of Experience Cloud (formerly Community) to access records associated with their accounts or contacts.
How it works:
- Define a User Profile (usually a community profile).
- Create a Sharing Set for this profile.
- Specify the Target Object (for example, a Case).
- Determine the access level (Read/Write).
- Use a mapping like: Case.Account ID = User.Contact.Account ID
Sharing Sets are useful for displaying data on portals without using Apex.
5. Apex Sharing using __share Objects
Sometimes declarative sharing in Salesforce is not enough. You may need to programmatically share records using Apex. In this case, __share objects are used.
Each custom object (with sharing enabled) has an [YourCustomObject]__Share object associated with it. For standard objects (such as AccountShare, ContactShare), predefined shared objects are used without double underscores.
How to use Apex Sharing:
- Enable “Allow shared access” to the object.
- Create a record in [YourCustomObject]__Share object.
Example: The company wants:
- All Opportunities with a budget of > $100k are shared with the “Executive Review" team.
- But only those Opportunities where region = “Europe".
This one is difficult to express through Sharing Rules, that is why a custom Apex logic is written, which creates records in the Opportunity__share object.
6. Profiles vs. Permission Sets
Profiles are the basic access granter. Each user has one profile that defines their:
- Object-level access
- Field-level access
- Record types
- Login hours
- Tab visibility
- App access
The permission sets are optional. They are used to grant additional permissions without changing the profile.
Recommended practice: use profiles for basic access and permission sets to grant permissions for specific functions.
Conclusion
Salesforce has a layered permissions model. It covers objects, fields, records, and advanced tools such as Apex sharing, thus providing distinctive flexibility. But with power comes the need for knowledge, understanding, and the ability to take advantage of such a wide range of permissions. The main thing is to be able to combine declarative tools (profiles, sharing rules, sharing sets) with programmatic management (Apex sharing).
Whether you are creating a secure portal, managing confidential sales data, or providing a personalized user experience, you need to understand and be able to set permissions correctly as it is the foundation to succeed in Salesforce.
