Criteria, Guest, Owner

Module 3 of 9 in the chapter Steve’s 25 Ways to Share a Record: The Map, chapter 5 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: When the org-wide default has locked a cabinet, how does an admin open it again for the right people, automatically, without touching each record?

Set 1 locked the cabinets. Set 2 is how the admin opens them again by rule. Salesforce describes sharing rules as “automatic exceptions to your org-wide sharing settings” (Sharing Rules (opens in a new tab), Salesforce Help, checked 2026-11-01). Three ways: criteria-based sharing rules, guest user sharing rules and owner-based sharing rules.

Every sharing rule has three parts. What am I sharing? Who am I sharing it with? And what level of access am I giving them, Read Only or Read/Write? The three kinds of rule differ only in the first question: how they pick the records.

Click to enlarge

What every sharing rule has in common

A few things hold for all three, and they’re worth knowing before the first rule:

• Rules only open. “Like role hierarchies, a sharing rule can never be stricter than your org-wide default settings.” That’s why you need a Private or Public Read Only default before you can create one (Sharing Rules; Sharing Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01).
• The most generous rule wins. “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).
• The office still has to be open. A rule can give Read/Write, but if the user’s profile and permission sets only give Read on the object, they get Read. They need both: the object permission for Edit and the share for Edit. That’s chapter 1’s rule, most restrictive wins.
• Salesforce keeps them up to date. “When you modify which users are in a group, role, or territory, the sharing rules are reevaluated to add or remove access as necessary,” and the same happens when records are transferred to a new owner (same page).

Way 5: criteria-based sharing rules

A criteria-based sharing rule “determines with whom to share records based on field values” (Sharing Rule Types (opens in a new tab), Salesforce Help, checked 2026-11-01). It’s studying the record, not the owner. The values must be on the record itself.

Here’s a demo I do. I have an object of airport runways, set to Private. Paul the pilot owns one runway, so Paul sees one runway. I create a public group, put Paul in it, and create a criteria-based rule: if the airport identifier contains the letter Z, share it with the group, Read Only. Save. Salesforce goes into recalculation: it works out which records match and writes rows into the share table for them. Refresh, and Paul sees every runway with a Z in its identifier. The criteria can be as arbitrary as that.

What you can use as criteria is limited. Salesforce lists record types and these field types: Auto Number, Checkbox, Date, Date/Time, Email, Lookup Relationship (to user ID or queue ID), Number, Percent, Phone, Picklist, Text, Text Area and URL. Note that Text and Text Area are case-sensitive: “Manager” doesn’t match “manager” (Sharing Rule Types). The lookup is only to a user or a queue. And you can’t use encrypted fields, formula fields, or “fields whose values are derived from other fields on the record” (Sharing Rule Considerations). You can combine several criteria with your own AND and OR logic.

So if the value you need isn’t on the record, or it’s a formula, you can’t share on it directly. You might need to create a new custom field, then populate and maintain it with an automation.

Criteria-based rules are available for “many objects, including accounts, assets, campaigns, cases, contacts, leads, opportunities, work orders, and custom objects” (Sharing Rule Types). Not every standard object. Check the Sharing Settings page in your own org.

Way 6: guest user sharing rules

If you build a site or an Experience Cloud site, there’s a guest user: the profile of the anonymous visitor who never logs in. How do you control which records the public can see? A guest user sharing rule. Salesforce says it’s “a special type of criteria-based sharing rule and the only way to grant record access to unauthenticated guest users” (Sharing Rule Types).

It works like a criteria-based rule: you choose the criteria and the access level, and the target is the guest user of one site. Read Salesforce’s warning before you save one: “By creating a guest user sharing rule, you’re allowing immediate and unlimited access to all records matching the sharing rule’s criteria to anyone” (same page). No login. Anyone. Ask what’s on those records, field by field.

And guest user rules count against the same 50 as criteria-based rules, not 50 more.

Way 7: owner-based sharing rules

An owner-based sharing rule “opens access to records owned by certain users” (Sharing Rule Types). Now the source isn’t the record’s fields, it’s who owns it: records owned by members of a group, a role, or a role and its subordinates.

This is where it gets powerful. The source can be a public group, and I can stick everything in that group. So an owner-based rule can be an enormously powerful vacuum cleaner: it picks up every record owned by anyone in the source group, and delivers access to everyone in the target group. One rule, a big source and a big target.

My example: records owned by the region one managers. Share them with the hardware VP and subordinates. Another rule shares with the software VP and subordinates. Another with the support VP. Each one picks up a set of records and delivers it to the people who need it.

Two details from Salesforce worth knowing. If the source is a queue, “only records owned by the queue are shared. Records owned by individual members of the queue aren’t shared.” And high-volume community or site users “can’t be included in owner-based sharing rules,” because they don’t have roles (Sharing Rule Considerations). Set 7 is how you share their records.

The target: a role, its subordinates, or a public group

The target matters as much as the source. Here’s a small hierarchy: a regional VP, a director below, a manager below, an assistant manager below.

• Share with the manager’s role, and the manager gets access. The director and the regional VP above get it too, through the hierarchy. But the assistant manager doesn’t. The assistant manager can’t help the manager work those records.
• Share with the manager’s role and subordinates, and the manager and everyone below get access. Choose this when people below do the work. A VP’s records aren’t much use if only the VP can see them.

And then there’s the public group. I call it a Swiss Army knife. Groups can contain users, roles, roles and subordinates, and other groups. Groups can contain groups can contain groups: an Arizona group, a California group, a Nevada group, and an all-US group containing all of them. Share with whichever level you need.

There’s a superpower hidden in the group, too. A public group has its own Grant Access Using Hierarchies checkbox: “When selected, any records shared with users in this group are also shared with users higher in the hierarchy” (Create and Edit Public Groups (opens in a new tab), Salesforce Help, checked 2026-11-01). People don’t even realize it’s there.

The limits: 50 and 300

Salesforce’s limit today: “You can define up to 300 total sharing rules for each object, including up to 50 criteria-based or guest user sharing rules, if available for the object” (Sharing Rules). So criteria-based and guest user rules share one bucket of 50, and every kind counts toward the 300.

Why the difference? I believe it’s the work behind each one. A criteria-based rule means Salesforce has to watch the fields on every save: has this record started or stopped matching a rule? An owner-based rule only has to watch for new records and owner changes. That’s my reasoning, not Salesforce’s.

What matters is how you use them. Say someone wants a criteria-based rule per state: if the account is in Arizona, share with the Arizona group; Nevada, the Nevada group; and so on for 50 states. Run away. Somebody will come along and say, what about Guam? And you’ve used them all up, with nothing left for anything else on that object.

So anytime there’s a pattern of more than about 10, I’d say don’t do it with criteria-based rules. Watch around 10 or 15, because 10 becomes 20 or 30. For owner-based rules, the question isn’t how many people a rule includes. You can widen a target as much as you like with a group. The question is how many separate buckets of sharing there are. If you’re heading for 200 to 300 separate buckets, you’re past what owner-based rules can do.

This is where I use Steve’s number of zeros. Whenever someone asks for a sharing rule, ask: how many will there be? Ten? A hundred? A thousand? The answer tells you whether a rule is the right way at all.

Don’t hard-code IDs

Have you ever opened a sharing rule and seen a criterion like “where the ID equals” something? I have. It’s a nightmare. Salesforce IDs differ between your sandboxes and production, so the rule can’t be deployed. If it’s created in production, it only works in production, and your sandboxes no longer behave the same. Try to avoid hard-coded IDs in sharing rules. When a scenario seems to need one, step back and find another pattern.

The share table: rule rows

In module 2, the account’s share table had one row: the owner’s. Sharing rules add rows. A sharing rule’s row has the row cause Rule, and a guest user rule’s row has GuestRule (AccountShare (opens in a new tab), Object Reference, Winter ‘27, checked 2026-11-01).

You don’t write these rows. Salesforce does, when you save the rule, and it rewrites them as records, groups, roles and owners change. When I ran my runway demo and queried the runway share table in Workbench, there were 46,000 rows. You’ll be able to see your shares in the share table, and you’ll be able to know what’s happening.

Click to enlarge

Where this goes deep

Chapter 7, Public Groups and Criteria-Based Sharing Rules, and chapter 8, Owner-Based Sharing Rules, take these apart: designing groups, the targets, guest user rules on sites, recalculation and how to stay inside the limits. For now, know the three, the three parts of every rule, and the two numbers.

What an architect decides here

• For each requirement, whether the records are picked by what’s on them (criteria) or by who owns them (owner).
• Whether the value a criteria-based rule needs is on the record, and if not, which field and which automation keep it there.
• The target: a role, a role and subordinates, or a public group, and whether that group grants access up the hierarchy.
• How many rules there will be, before the first one is built, against the 50 and the 300.
• For any site, exactly which records the guest user can see, and why each one is safe for anyone.
• That no sharing rule depends on a hard-coded ID.

Beyond the exam: what AI changes. A sharing rule shares with everyone in its target, and an agent’s user can be in a group like anyone else. Before you add an agent’s user to a public group, read every rule that targets the group: the agent will see all of it, and answer questions from it. And on a public site, whatever a guest user rule opens is open to anyone, including any agent or tool that reads the site. Chapter 20 covers agents.

Explore

• Sharing Rules (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Sharing Rule Types (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Sharing Rule Considerations (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Create and Edit Public Groups (opens in a new tab), Salesforce Help (checked 2026-11-01)
• AccountShare (opens in a new tab), Object Reference (checked 2026-11-01)