Who can see what in Salesforce?

A guide to demystify the Salesforce data security model

Determining who can see specific records or fields in Salesforce can be a time-consuming and frustrating task. Profiles, permission sets, permission set groups, field-level security, and many forms of record-level sharing mechanisms all add new layers to the security model, making it challenging to find the exact reason why someone does not have the access they need.

This blog untangles the complexity of the Salesforce security model for you by walking you through the complete security model, making it faster to determine users’ real, effective access, as well as spot overprivileged access.

This blog covers:

• Object-level security:
  • Admin-level system permissions
  • Object permissions
• Field-level security:
  • Field permissions
  • Edit Read-Only Fields and View All Fields
• Record-level security:
  • Organization-wide sharing defaults
  • Role Hierarchy
  • Sharing Rules
  • Manual Sharing
  • Restriction Rules

It’s important to understand that object-level access, record-level access, and field-level access are intertwined in determining the user's access. For example, record-level sharing can’t share records to users that don’t have object and field permissions to that object.

Object-level security

The first level of the Salesforce security model is object-level security, which controls which Salesforce objects a specific user can access. Without access to the object itself, none of the other access mechanisms (record and field-level security) matter.

Admin-level system permissions

Before diving into object permissions, it’s important to note that there are two types of administrative system permissions in Salesforce that override ALL object permissions (but not field permissions) and grant the user access to all objects in the Salesforce Org. These are:

1. View All Data
2. Modify All Data

Object permissions

In Salesforce, the access to individual objects is controlled by object permissions, granted by user’s profile, permission sets, and permission set groups. There are six types of object permissions:

1. Create
2. Read
3. Edit
4. Delete
5. View All Records
6. Modify All Records

Create, Read, Edit, and Delete (1-4) are subject to record-level sharing mechanisms, granting the user base level access to the object, but not granting any record access.

View All Records and Modify All Records (5-6), however, grant the user access to ALL records within the given object, overriding the record-level sharing.

REMEMBER: Permissions View All Data, Modify All Data, View All Records, and Modify All Records override record-level security, but not field-level security.

Field-level security

Field-level security determines which fields of the object the user can access. There are two types of access:

1. Read
2. Edit

Similarly to object permissions, field permissions are granted to a user by profile, permission sets, and permission set groups.

Field permissions are treated separately from system and object permissions, with a couple of exceptions:

• Edit Read-Only Fields is a system permission that grants access to edit fields that would otherwise be marked as read only. Note that the user would still need the “edit” object permission to make use of this system permission.

• View All Fields is a brand new object permission added to Salesforce in the Spring ‘25 release. This permission grants the user read access to all fields within the given object, overriding any field permissions to that object.

Confused yet by the many levels of permission sets? This is one reason AI is used to manage complex Salesforce environments efficiently. You can demo Valo’s approach here to see what administrative work you can offload, but keep reading to learn more.

Record-level security

As mentioned previously, solely having object permissions is not enough to view records in Salesforce. This is where record-level access comes into the picture. Apart from a few exceptions mentioned above that grant access to all records within the given object, user’s access to individual records in an object is determined by record-level security.

REMEMBER: record-level access only matters if the user has object permissions to the object.

Organization-wide sharing defaults

Organization-Wide Defaults set the baseline for who can access records of a specific object. Organization-wide defaults are object-specific, and they are set separately for internal and external users. For most objects, there are three available settings:

• Private
• Public Read
• Public Read/Write

When the default is Private, only record owner, users above the record owner in role hierarchy, and users with administrative object-level access, can access the record. Additional access can be granted with sharing rules and manual sharing. When the default is Public Read or Public Read/Write, all users can access records in the given object.

When Valo customers connect to the solution, they can see across multiple orgs and understand users more deeply. This level of insight can significantly reduce the time spent on managing access rights.

Role hierarchy

Salesforce’s role hierarchy grants a user access to records owned by or shared to not only themselves, but also their subordinates in the role hierarchy. This hierarchy-based sharing is enabled for most standard objects, and can not be disabled for those. For custom objects, you can select whether the hierarchy sharing is enabled or not by toggling the “Grant Access Using Hierarchies” setting in Organization Wide Defaults.

Sharing rules

There are essentially two types of sharing rules in Salesforce for granting record access to authenticated users:

1. Owner-Based Sharing Rules
2. Criteria-Based Sharing Rules

Owner-Based Sharing Rules are used to share records based on the record owner, either via a role (if specified, also its subordinates) or a public group that the record owner belongs to. Criteria-Based Sharing Rules are used to share records based on certain criteria applied to field values, sharing all records that match that criteria.

In addition, you can grant record access to unauthenticated guest users using Guest User Sharing Rules, which is useful for granting guest users of Experience Cloud sites access to specific Salesforce data.

Valo customers that need to comply or report on security will use the solution to automatically monitor for suspicious behavior 24/7. Misconfigurations in record sharing can happen easily, especially if an admin is new and/or inherited a complex environment.

If your Salesforce Org uses Sales Territories (previously Enterprise Territory Management), there are additional sharing mechanisms available for sharing records based on territory assignments.

NOTE: Salesforce limits the number of sharing rules per object to 300 total sharing rules, and to 50 criteria-based rules.

Manual sharing

Manual Sharing can be used for sharing individual records to another user in exceptional cases where you don’t want to create a new sharing rule. However, note that large amounts of manual shares can cause performance issues, which is why you should always consider creating a sharing rule when sharing a large number of records. Salesforce recommends that a user is the recipient of at most 10,000 manual shares to avoid performance issues.

Restriction rules - an exception

In addition to the different mechanisms for granting access, Restriction Rules can be used to restrict user’s access to specific records. They are applied after everything mentioned above to determine which records the user can actually access.

Because Restriction Rules can be used to restrict the access, they are an exception to other sharing mechanisms in Salesforce that generally start from less permissive defaults and open up the access when needed.

Wrapping it up - managing user access

Hopefully this article provides a good understanding of how the Salesforce security model works as a whole. There is more to each of these levels, and especially the record sharing goes much deeper than what I covered here.

The key takeaway is that object-level security, record-level security, and field-level security are all intertwined, and you need all three to make sure your Salesforce users have the right accesses for their usage.

You probably also recognize by now that the complexity and depth of Salesforce can accidentally introduce risky misconfigurations or accidental over-sharing. This is one of the many reasons Salesforce administrators choose Valo, to provide them real-time insights and actions for better security, productivity and cost management, which you can experience live by booking a Valo demo here: https://www.valo.ai/request-demo

About Antti

Antti is responsible for UX design and frontend development at Valo. With a strong cross-disciplinary skillset, he is committed to bridging design and technology to create intuitive user experiences and drive innovative solutions. Outside of work, he enjoys running, freestyle skiing, and playing tennis.

• 

  Antti Norrkniivilä