Let’s face it - Salesforce record sharing is a maze with complex nuances, and if you as an Admin don’t know exactly what you’re doing and how your Org is set up, it’s a very real possibility that at least some sensitive data is exposed to wrong users. This is a top of the mind issue especially now when the Salesforce ecosystem is diving head first into the world of AI Agents.

Human users vs. AI Agents

Most of the time, human users are not even aware of all the access they might have. The data they have access to might be hidden from them in the UI, it might require lots of digging to find it in the Org, and the humans often need to know specifically what they want to find, or else the odds are that they will never come across the sensitive data even when it’s shared to them.

AI Agents, on the other hand, are something else. All it takes is one question, and you can be sure that the Agent is going to surface the sensitive data from the depths of your Org and suddenly reveal the overprivileged record sharing settings that didn’t matter quite as much when human users were the only ones using the Org. The adoption of AI Agents amplifies the effects of ill-defined sharing settings tenfold, which is why it’s crucial to have the confidence in your sharing settings before adopting AI Agents on a larger scale. The multitude of sharing mechanisms presents a challenge to keeping everything under control, and this article presents a few quirks which are not always obvious when determining record access.

Quirk 1: Overly permissive permission sets and profiles

The basic principle behind Salesforce’s data security model is that object and field permissions define the base level access to objects, and record sharing mechanisms define which actual records the user can access. Permission sets and profiles control the base level access, and organization-wide defaults, role hierarchy, sharing rules, territories, and manual sharing control the record access. The user needs all three to access a record and its fields, and most of the time, they don’t overlap. This is neat and keeps things organized, with a few exceptions.

Salesforce provides a couple permissions to completely overwrite the record access controls with the permission sets. Permission sets can grant “View All Records” or “Modify All Records” permissions to objects, which grant the user access to all records, skipping all sharing mechanisms. This is often used to improve performance and make administrative work easier, but at the same time it introduces risks, because investigating who can access a specific record via sharing settings does not reveal users with these permissions.

The Salesforce Spring ‘25 Release also introduced a new permission “View All Fields”, which overrides the field permissions in a similar fashion as “View All Records” overrides the sharing mechanisms.

Quirk 2: Inherited access through hierarchy or nested group membership

Salesforce sharing rules can grant access to public groups, roles, or territories, and users get access by belonging to these, as sharing rules can not share records directly to users.

Nested groups

An important characteristic of public groups is that they can have other groups as members. Group A can be a member of Group B which is a member of Group C, and if a sharing rule grants access to Group C, it means that also Group B and Group A inherit access because they are members of Group C. This is not obvious in the Salesforce UI, and especially if groups have nesting of multiple levels, tracing down all the possible access that users of a specific public group have is very cumbersome.

Role hierarchy and sharing rules

Role hierarchy defines the record access based on record ownership, and by default, the users belonging to roles higher up in the hierarchy get access to all the records owned by their subordinate roles. Role hierarchy can also be used to define sharing rules’ sources and targets. Sharing rules can be set up to share records to a specific role and all its subordinates, and ownership-based sharing rules can also share records owned by a specific role or any of its subordinates.

This subordinate-based sharing is also challenging to detect, because it’s not sufficient to rely on knowing which records are shared to the role a user belongs to, but they might also inherit access to records shared with their parent role and subordinates. This works also in another direction: To know for sure whether a record owned by a user is shared via sharing rules, one needs to also check all the parent roles’ sharing rules.

Quirk 3: Sharing of child objects controlled by parent object

The basic tenet of sharing mechanisms is that they are specific for each object. For example, the sharing settings set up for Accounts do not affect how Campaigns are shared. There are, however, a couple mechanisms that make this a bit more complex: parent/child objects, which come in two forms of relationships: Master-Detail relationship (stricter, child can’t exist without a parent) and lookup relationship (child can exist even without parent). For some standard objects with lookup relationships (for example Account → Contact or Campaign → CampaignMember), there’s an option called “Controlled by Parent” which can be toggled from the object’s organization-wide defaults, and make tracking record access a bit tricky. This option is also enabled for all Master-Detail relationships.

As an example of the Account → Contact relationship, if the “Controlled by Parent” option is enabled for the Contact object (child), it inherits the sharing model of Account (parent). This means that role hierarchy and ownership of Contact records don’t affect the access of Contacts, it’s all inherited from the Account. However, since this is a lookup relationship, Contacts can also exist without a parent Account. In this case, when the “Controlled by Parent” is enabled for Contacts, these Contacts are only visible to their record owner. Also, when the “Controlled by Parent” option is enabled, Contacts can’t be shared independently from a parent Account.

Summary

This article covered three important quirks of the record sharing model in Salesforce that easily go under the radar given the complexity of the sharing model. In a follow-up article, I will be covering a few more to help you understand the potential blind spots in your Org better. Before scaling your AI Agent adoption, review your Org’s access controls with a purpose-built tool like Valo to surface the hidden misconfigurations of record sharing.

Here’s a summary of what this article covered:

• Permission sets granting “View All Records” or “Modify All Records” permission overwrite all record-level sharing mechanisms
• Nested group memberships and sharing with role hierarchies can cause sharing to groups and roles that’s very cumbersome to detect
• If “Controlled by Parent” option is enabled for a child object, it inherits sharing mechanisms of its parent, replacing all sharing mechanisms defined for the child object

About the Author

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ä