Choosing Whose Records and Who Gets Them
Module 2 of 4 in the chapter Owner-Based Sharing Rules, chapter 8 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.
The question this module answers: An owner-based rule has two buckets of people: whose records it picks up, and who receives them. How do you choose each one so the rule reaches exactly who you mean?
Every owner-based rule has a source bucket and a target bucket. The source is “owned by members of.” The target is “Share with.” Both are picked from the same short list of categories, and the choice is final once you save (module 1). So this is the decision to get right.
To get it right, you need to know your role hierarchy.
The categories
Section titled “The categories”When you define a sharing rule, “you can choose from the following categories in the owned by members of and Share with dropdown lists. Depending on the type of sharing rule and the features enabled for your organization, some categories may not appear” (Sharing Rule Categories (opens in a new tab), Salesforce Help, checked 2026-11-07). For your internal users, the ones you’ll use are these:
| Category | Who’s in it | Source, target or both |
|---|---|---|
| Public Groups | Everyone in the group, and in the roles and groups inside it | Both |
| Roles | “all of the users in the specified role” | Both |
| Roles and Internal Subordinates | The role, “plus all of the users in roles below that role, excluding site and portal roles” | Both |
| Territories, and Territories and Subordinates | The territory, or the territory and all territories below it | Both, where territories are on (chapter 9) |
| Queues | “All records owned by the queue, excluding records owned by individual members of the queue” | Source only |
| Managers Groups, and Manager Subordinates Groups | A user’s managers, or a manager and their reports | Chapter 7, module 1 |
All from Sharing Rule Categories. Two more need care. Roles and Subordinates is “Deprecated. Use Roles and Internal Subordinates instead.” And Roles, Internal and Portal Subordinates includes site and portal roles, so it reaches external users. If you pick it, or Portal Roles, as a target, “you get an alert when you save the sharing rule” (Sharing Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07). Read the alert. Chapter 14 covers external users.
Go downward, or not
Section titled “Go downward, or not”Here’s how I teach the target. Look at the role hierarchy, find the person you’re sharing with, and ask one question: do you want to go downward?
Say you want to share some records with the regional vice president of region 2.
- Target: Region 2 VP, the role. Only the people in that role get the records.
- Target: Region 2 VP, role and internal subordinates. The VP gets them, and so do the managers and assistant managers below them. It grants downward.
Either way, it skips region 1, because region 1 is a different branch. And either way, the senior VP above region 2 gets them too, because of the hierarchy. “Users in the role hierarchy are automatically granted the same access that users below them in the hierarchy have from a sharing rule,” for standard objects, or for custom objects with Grant Access Using Hierarchies selected (Sharing Rule Considerations).
So the hierarchy always carries access upward. Subordinates carry it downward only if you ask. If you want to go downward, include subordinates. If you don’t, don’t.
One rule, or several
Section titled “One rule, or several”Now a bigger example from class. Records owned by the region 1 managers need to reach the product side: the hardware VP and their team, the software VP and their team, and the support VP and their team.
You could target each one with its own rule: hardware VP and subordinates, then software, then support. Three rules with the same source.
Or you put those three roles, each with its subordinates, in one public group, and target the group. If they all have the same source, you don’t need to create multiple rules. And it works on the source side too: put the region 1 managers’ role in a group, and next year, when region 3 needs the same, you add region 3 to the group, not a rule.
That’s the power of the group: you can add more to it at the source or at the target, without touching the rule. Groups on both sides are what make one owner-based rule a vacuum cleaner (module 1).
When it’s really three different decisions, though, keep three rules. If hardware should only get hardware records, that’s not an owner question anymore. It’s about what’s on the record, and module 3 helps you choose.
Same bucket on both sides
Section titled “Same bucket on both sides”The source and the target can be the same bucket. Salesforce’s own example shares “all account records owned by the Sales Rep role with the same Sales Rep role” (Create Owner-Based Sharing Rules (opens in a new tab), Salesforce Help, checked 2026-11-07). It’s how peers see each other’s work under a Private default: same team, same records.
Two cautions. A role as both source and target is one rule per role; with many teams, that adds up quickly against the 300 (chapter 7, module 4). And remember that a second rule with the same source and target overwrites the first (module 1).
What else the rule reaches
Section titled “What else the rule reaches”A rule on one object can reach records on another.
- Up to the account. “Sharing rules automatically grant additional access to related records. For example, opportunity, contact, or case sharing rules give role or group members access to the account associated with the child record” (Sharing Rule Considerations).
- Down from the account. An account rule asks for more than one level. You set the access to the accounts, and also to their contacts, opportunities and cases, where Private is an option (Create Owner-Based Sharing Rules). “Contact Access isn’t available when the organization-wide default for contacts is set to Controlled by Parent” (same page).
So when you share accounts, decide the children on purpose. Read/Write on the account doesn’t have to mean Read/Write on every opportunity. Chapter 10 covers the access you get for free through these relationships.
And the user’s own access still decides
Section titled “And the user’s own access still decides”The target gets the share. It doesn’t get the object. As module 1 says, the users must have profile and permission set access to match the level you share. And “If multiple sharing rules give a user different levels of access to a record, the user gets the most permissive access level” (Sharing Rule Considerations). So when you plan a target, look at every rule that already reaches those people, not just this one.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video on owner-based rules: the source bucket, the target bucket, and where the target sits in the role hierarchy. The note under the video says what’s still right and what’s changed since.
What an architect decides here
Section titled “What an architect decides here”- For each rule: the source bucket and the target bucket, picked from the categories, with the reason.
- For each role in a target: go downward or not. Roles and Internal Subordinates only where the people below need the records.
- Who above the target gets the records through the hierarchy, and, for custom objects, whether Grant Access Using Hierarchies should be on.
- Where targets reach external users (Roles, Internal and Portal Subordinates, Portal Roles), and whether they should.
- Where several targets share one source: one rule to a group, or separate rules because the decisions really differ.
- For account rules, the access to contacts, opportunities and cases, each set on purpose.
Beyond the exam: what AI changes. “Share the region 1 managers’ opportunities with the product teams” sounds like one instruction. An agent that builds the rule has to turn it into a source, a target and a category, and “the product teams” could mean three roles, three roles with their subordinates, or a group. Each one reaches different people. Ask the agent which category it chose on each side before you accept the rule, because neither side can change after it’s saved.
Explore
Section titled “Explore”- Sharing Rule Categories (opens in a new tab), Salesforce Help (checked 2026-11-07)
- Create Owner-Based Sharing Rules (opens in a new tab), Salesforce Help (checked 2026-11-07)
- Sharing Rule Considerations (opens in a new tab), Salesforce Help (checked 2026-11-07)