Sharing by Who Owns the Record

Module 1 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: When one team’s records must be seen by another team, how does a sharing rule share them by who owns them, and what does it watch to keep that true?

Here’s Salesforce’s own example. Your org-wide default for accounts is Private, so each sales rep sees only the accounts they own. But the sales reps want to see each other’s accounts. You “Create an owner-based sharing rule that 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).

Nothing on the account record decides it. Not the region, not the type, not the status. Only who owns it.

Chapter 5, module 3 put this rule on the map as way 7. This chapter takes it apart.

The source is the owner

An owner-based sharing rule “opens access to records owned by certain users” (Sharing Rule Types (opens in a new tab), Salesforce Help, checked 2026-11-07). Salesforce’s second example: sales managers in one region need to see the opportunities owned by sales managers in another. “The U.S. sales manager could give the APAC sales manager access to the opportunities owned by the U.S. team using owner-based sharing” (same page).

Compare it with a criteria-based rule (chapter 7). A criteria-based rule is studying the record. An owner-based rule is studying the owner. The source isn’t a field value; it’s a set of people, and every record they own.

The vacuum cleaner

This is where it gets powerful. The source can be a public group, and remember, I can put almost anything into that group (chapter 7, module 1). Users, a role, a role and its subordinates, other groups.

So an owner-based rule can be an enormously powerful vacuum cleaner. It sucks up every record owned by anyone in the source group, and by anyone in the groups and roles inside it. Whatever I put in the group becomes the source of the share. Then I decide who the target is, and the target can be a group as big as the source.

Between the two, you can do a lot with one rule. You can scoop up a bunch of people, whatever they own and whatever their subordinates own, and share it with another set of people and their subordinates.

Click to enlarge

Five steps to build one

In Setup, under Sharing Settings, you open the object’s Sharing Rules list and click New (Create Owner-Based Sharing Rules). Then it’s five steps.

Name it. A label, a rule name, and a description of up to 1,000 characters. Write why the rule exists. Chapter 7, module 5 shows why that matters years later.
Choose the type: Based on record owner.
Which records: owned by members of a group, a role, a role and its subordinates, a territory, or a queue. That’s the source.
Who gets them: Share with a group, a role, a role and its subordinates, or a territory. That’s the target.
How much: the access level.

Module 2 goes through every choice in steps 3 and 4.

The level, and the profile behind it

For most objects the level is Read Only or Read/Write. On an account rule you also set access to the account’s contacts, opportunities and cases, where Private is an option. Full Access is for campaigns only (Create Owner-Based Sharing Rules).

And the level is the most a rule gives. It’s not the most a user gets. You can grant them Read/Write, but if their profile and permission sets only allow Read on that object, they won’t get Write. They need both: the object permission for Write and the share for Write. The users must have profile and permission set access to match the level you share (chapter 3 covers object permissions).

If two rules give the same user different levels on the same record, “the user gets the most permissive access level” (Sharing Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07).

What Salesforce watches

A criteria-based rule depends on the record’s fields, so any edit can move a record into or out of it. An owner-based rule depends on two things only: who owns the record, and who’s in the source and target. Salesforce’s considerations list when it re-evaluates (Sharing Rule Considerations):

A new record. “Sharing rules apply to all new and existing records that meet the definition of the source dataset.”
A new owner. “When you transfer records from one user to another, the sharing rules are reevaluated to add or remove access to the transferred records as necessary.”
A change of people. “When you modify which users are in a group, role, or territory, the sharing rules are reevaluated to add or remove access as necessary.” That’s both sides: a new owner in the source brings their records in, and a new member of the target gets access.
A change to the rule. A new access level updates every record; deleting the rule removes the access it created.

Editing a field on the record doesn’t change what an owner-based rule shares. That’s why I believe Salesforce allows 300 rules but only 50 criteria-based ones: an owner-based rule only has to watch for new records and owner changes, not every field on every save. That’s my reasoning, not Salesforce’s. Chapter 7, module 4 covers the limits.

Click to enlarge

Four things that surprise people

Inactive owners still count. “Sharing rules apply to active and inactive users” (Sharing Rule Considerations). When someone leaves and their user is deactivated, their records stay shared by the rule until someone transfers them.
A queue shares only its own records. “If you share records owned by a queue in an owner-based sharing rule, only records owned by the queue are shared. Records owned by individual members of the queue aren’t shared” (same page). A queue can be a source, never a target: it’s “Available only in the owned by members of list” (Sharing Rule Categories (opens in a new tab), Salesforce Help, checked 2026-11-07).
Some owners can’t be a source. “High-volume community or site users, Chatter External, and Chatter Free users can’t be included in owner-based sharing rules.” For high-volume users’ records, use a criteria-based or guest user rule (Sharing Rule Considerations; chapter 7, module 2).
The same source and target means the same rule. “Creating an owner-based sharing rule with the same source and target groups as an existing rule overwrites the existing rule” (same page). You don’t get two rules; you replace the first one, and its access level with it.

Some choices are final

“For owner-based sharing rules, you can edit only the label, rule name, and sharing access level. If you must edit other fields, delete the rule and create a new one” (Create Owner-Based Sharing Rules).

So the source and the target are both final. That’s twice the reason to use groups on both sides. If the rule’s source is a group, you change who’s in the group, not the rule. If you’d chosen a role and the org reorganizes, you’re deleting the rule, which removes every share it wrote, and creating a new one, which writes them all again.

What an architect decides here

For each owner-based rule: whose records (the source), who gets them (the target) and how much, written in the rule’s description with the reason.
Groups as the source and the target wherever you can, because neither can be changed after saving.
That the users in the target have the object permissions to match the level you share.
What happens to the records of users who leave: transferred, or still shared by the rule while their owner is inactive.
Where records are owned by queues, whether a rule on the queue is what you mean, since it doesn’t reach the queue members’ own records.

Beyond the exam: what AI changes. An owner-based rule shares what a set of people own. More and more records are created by automation and agents, and someone has to own each one. If every record an agent creates is owned by one integration or agent user, an owner-based rule on that user shares all of them at once, and a rule on the people who asked for them shares none. So decide who owns what agents create before you write rules on owners. Chapter 20 covers agents.

Explore

Create Owner-Based Sharing Rules (opens in a new tab), Salesforce Help (checked 2026-11-07)
Sharing Rule Types (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)
Sharing Rule Categories (opens in a new tab), Salesforce Help (checked 2026-11-07)