Skip to content
SteveTechArcSteveTechArc Courses

Owner-Based or Criteria-Based? Choosing the Sharing Rule

Module 3 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: A sharing requirement comes in. Do you share by who owns the record, or by what’s on it?

Two requests come in on the same day.

  • “The support desk needs to see every account the sales team owns.”
  • “Every case marked Escalated goes to the escalation team, whoever owns it.”

Both are sharing rules. They’re not the same kind. The first is about who owns the records. The second is about what’s on the record. Get that question right first, and most of the design follows.

Follow the owner, or follow the record

Section titled “Follow the owner, or follow the record”

An owner-based rule is studying the owner. A criteria-based rule is studying the record. So ask: when this record should be shared, what makes it so?

  • If the answer is a person or a team, use owner-based. “Accounts the sales team owns.” “Opportunities owned by the region 1 managers.” Change the owner, and the access should change with it.
  • If the answer is a value, use criteria-based. “Cases marked Escalated.” “Applications for the IT department.” Change the owner, and nothing should change. Change the value, and it should.

Salesforce’s own examples split the same way. Owner-based: “The U.S. sales manager could give the APAC sales manager access to the opportunities owned by the U.S. team.” Criteria-based: share “all job applications in which the Department field is set to ‘IT’ with all IT managers” (Sharing Rule Types (opens in a new tab), Salesforce Help, checked 2026-11-07).

What each one follows

Section titled “What each one follows”

Here’s the same record, transferred from a rep in region 1 to a rep in region 2.

  • An owner-based rule on “owned by region 1” stops sharing it, and a rule on “owned by region 2” starts. “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” (Sharing Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07). The access followed the owner.
  • A criteria-based rule on “Region equals West” doesn’t care. The record is still West until someone, or some automation, changes the field. The access followed the record.

Neither is wrong. They answer different questions. The mistake is choosing one when the business means the other: sharing by owner when the record’s region is what matters, so a transfer quietly moves access to the wrong team.

Who can change the input

Section titled “Who can change the input”

Every rule has an input, and whoever can change the input can change who sees the record. So it’s a security question, not just a design one.

  • Owner-based: the input is the owner and the people. Whoever can transfer records, change a user’s role, or change a group’s membership is changing access. That’s usually admins and managers, and a transfer is visible in the record’s history.
  • Criteria-based: the input is a field. Whoever can edit that field, or whatever automation fills it, is changing access, on every save (chapter 7, module 2).

The 50 inside the 300

Section titled “The 50 inside the 300”

The budget points the same way. “You can define up to 300 total sharing rules for each object, including up to 50 criteria-based or guest user sharing rules” (Create Sharing Rules (opens in a new tab), Salesforce Help, checked 2026-11-07).

I believe that’s because of the work behind each one. A criteria-based rule means Salesforce has to watch the fields on the object: has this change made a record start or stop matching? An owner-based rule only has to watch for new records and owner changes. That’s my reasoning, not Salesforce’s. But the practical result is plain: criteria-based buckets are scarce, and owner-based ones are wider and carry less overhead.

And each separate bucket of records consumes a sharing rule, whichever kind it is. So if the buckets line up with who owns the records, use owner-based. If you start to get one per state, you could potentially group it by owners, but you cannot group it by criteria. Chapter 7, module 4 has the full method: the number of zeros, and how many buckets each kind can hold.

Owner-based or criteria-based Owner-based or criteria-based. Owner-based: decided by who owns the record; re-evaluated on new records, owner changes and people moving in or out of the source or target; follows the record when it's transferred; its input is changed by whoever transfers records or changes roles and groups; up to 300 per object. Criteria-based: decided by a value on the record; re-evaluated when that value changes; ignores who owns it; its input is changed by whoever can edit the field, or the automation that fills it; up to 50 per object, inside the 300. Footnote: ask what makes the record shared: a person or team means owner-based, a value means criteria-based. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-01", "id": "DGM-SVA-OB-05", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} Owner-based follows the owner Decided by who owns the record Re-evaluated on new records, owner changes and people moving Moves with the record when it's transferred Input: whoever transfers records or changes roles and groups Up to 300 per object Criteria-based follows the record Decided by a value on the record Re-evaluated when that value changes Ignores who owns it Input: whoever can edit the field, or the automation that fills it Up to 50 per object, inside the 300 Ask what makes the record shared. A person or team: owner-based. A value: criteria-based. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Don’t fake one with the other

Section titled “Don’t fake one with the other”

There’s one trap I want you to see. A criteria-based rule can read a lookup to a user or a queue (Sharing Rule Types), and the owner is a lookup to a user. So you can write a criteria-based rule that says “Owner equals” one user.

Don’t. The value in the rule is that user’s ID, hard-coded, and it won’t travel between your orgs (chapter 7, module 5). It covers one person, not a team, and it uses one of your 50 to do what an owner-based rule does better. If the answer is who owns it, use the rule that’s built for owners.

When the answer is both

Section titled “When the answer is both”

Now the example from class. The records are opportunities owned by the region 1 managers. If the opportunity is for hardware, it should go to the hardware VP and subordinates. Software goes to the software VP and subordinates. Services go to the support VP and subordinates.

The source is about the owner. The split is about the record. An owner-based rule can scoop up the region 1 managers’ opportunities, but it can’t look inside them to see the product. A criteria-based rule can see the product, but it can’t see the owner’s role.

So bring the owner onto the record. Add a field for the owning region, and fill it with an automation from the owner’s role, the way chapter 7 module 2 fills any field a rule needs. Then three criteria-based rules: region 1 and hardware, region 1 and software, region 1 and services, each to its VP and subordinates. Three of your 50, and the automation is now part of your sharing model. If the product split doesn’t matter and every product team should see all of region 1, it’s one owner-based rule to a group holding all three (module 2).

Choosing the rule Choosing the rule. A sharing requirement: who needs which records? First question: does access follow who owns the record? If yes, an owner-based rule, one of up to 300 per object. If not: does it follow a value on the record itself? If yes, a criteria-based rule, one of the 50, with a field added and filled by an automation if the value isn't there yet. If not: is it one record at a time, chosen by a person? If yes, manual sharing or teams, chapter 9. Otherwise, code or a flow writes the shares, chapter 11. Footnote: then ask how many separate buckets there will be, chapter 7 module 4. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-01", "id": "DGM-SVA-OB-06", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "flow/decision 0.1.0", "theme": "stevetecharc 1.4.0"} A sharing requirement who needs which records? Does access follow who owns the record? An owner-based rule one of up to 300 per object Does it follow a value on the record itself? A criteria-based rule one of the 50; add a field and an automation if needed Is it one record at a time, chosen by a person? Manual sharing or teams chapter 9 Code or a flow writes the shares chapter 11 yes no yes no yes no Then ask how many separate buckets there will be (chapter 7, module 4). HOW TO READ IT a step the step that matters most a question an answer yes goes right to an answer; no goes down to the next question © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

What an architect decides here

Section titled “What an architect decides here”
  • For each sharing requirement: what makes the record shared, a person or team, or a value on the record.
  • What should happen to access when the record is transferred, and whether the rule you chose does that.
  • Who can change each rule’s input: who can transfer records and change roles and groups, and who can edit the fields criteria-based rules read.
  • How many of the 50 criteria-based rules each object can spend, and which requirements can use owner-based rules instead.
  • Where a requirement needs both, which field brings the owner onto the record, and what automation fills it.
  • That no criteria-based rule matches the Owner field to one user’s ID.

Beyond the exam: what AI changes. Agents transfer records. An agent that reassigns cases to whoever is free, or moves accounts after a territory change, is changing owners all day. Every owner-based rule on that object moves access with each transfer, and every criteria-based rule stays where it was. Before you let an agent reassign records, read the object’s rules and decide whether access should move with the owner.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.