Sharing by What's on the Record
Module 2 of 6 in the chapter Public Groups and Criteria-Based Sharing Rules, chapter 7 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.
The question this module answers: How does a criteria-based sharing rule decide who sees a record, and what do you design around it so it keeps working?
A criteria-based sharing rule is studying the record. What drives the rule is the record: if the record has a value in a field, share it.
The three parts of every rule
Section titled “The three parts of every rule”There are three parts to every sharing rule, and if you remember nothing else from this module, remember these three:
- The source: what am I sharing? The records that match. For a criteria-based rule, that’s a field value on the record.
- The target: who am I sharing it with? A public group, a role, a role and its subordinates, or a territory.
- The level: how much? Am I giving them Read Only or Read/Write?
In class I use a made-up object so nobody gets attached to its meaning: if the record’s name contains “East,” share it Read/Write with the East Coast users. Salesforce’s example is more realistic: a custom object for job applications with a Department picklist, and a rule that shares every application where Department is IT “with all IT managers in your organization” (Create Criteria-Based Sharing Rules (opens in a new tab), Salesforce Help, checked 2026-11-07). Source: applications where Department is IT. Target: the IT managers. Level: Read Only.
Chapter 5, module 3 showed my Z-runway demo. This module goes under that demo and into the design.
What happens when you save
Section titled “What happens when you save”In the demo, the object is airport runways, Private. A pilot owns one runway and sees one. I put the pilot in a public group, then create a rule: if the airport identifier contains Z, share it with the group, Read Only. Save.
Then Salesforce goes into recalculation. What’s happening behind the scenes is that Salesforce is determining which records match, and creating records in the share table for them, one row per record for the group. When I query the runway share table in Workbench afterwards, there are 46,000 share records on that one object. Every rule adds its rows to that table.
And the rule doesn’t run once. “Sharing rules apply to all new and existing records that meet the definition of the source dataset” (Sharing Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07). A new runway with a Z is shared when it’s saved. Change the identifier so it stops matching, and the access that rule gave goes with it. It’s looking at attributes of the record, and therefore it can be expensive. That’s part of why Salesforce limits how many you can have (module 4).
Design the field you share on
Section titled “Design the field you share on”Remember: you’re limited to criteria on the record itself. Here’s what that means, field by field.
What you can share on. 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. Text and Text Area are case-sensitive: “Manager” doesn’t match “manager” (Sharing Rule Types (opens in a new tab), Salesforce Help, checked 2026-11-07).
What you can’t share on. Two things surprise people every time:
- Relationships. The rule can’t reach through a relationship. You can’t share a case because of a field on its account. And the only lookups it reads are to a user or a queue: “In criteria-based sharing rules, you can’t use lookup fields” (Sharing Rule Considerations).
- Formulas. The same sentence goes on: you can’t use “encrypted fields, formula fields, or fields whose values are derived from other fields on the record” (Sharing Rule Considerations). A formula that pulls the account’s region onto the case looks like the answer. It isn’t.
If a field type isn’t on Salesforce’s list, such as a multi-select picklist, don’t plan a rule on it. And the value in the rule “is always a literal number or string,” up to 240 characters (Create Criteria-Based Sharing Rules).
So if you don’t have the exact criteria you need on the record, you create a new custom field, then populate and maintain it with an automation. Salesforce says the same: copy the value into “a text or numeric field. Then use that field as the criterion” (same page).
That makes the field a security control, and it needs designing like one:
- Who can edit it? Anyone who can change that field can move a record into or out of a rule. Use field-level security (chapter 4) so only the people or the automation that should set it can.
- What fills it? If an automation maintains it, the automation’s logic is now part of your sharing model. Test it like sharing.
- Blank values. “Using blank values in criteria-based sharing rule conditions with equal and not equal operators isn’t recommended” (Sharing Rule Considerations). Decide what an empty field means, and fill it.
- Record types. If you share on record type, “the label is used, not the developer name. To avoid issues, make sure the record type’s label and its translations are unique” (same page). In an org with many languages, two record types whose labels translate to the same word can break a rule that reads them.
The target and the level
Section titled “The target and the level”Who. The target can be a public group, a role, a role and internal subordinates, a territory, or a manager group (module 1). For roles that reach external users, Roles, Internal and Portal Subordinates, Salesforce warns you when you save (Create Criteria-Based Sharing Rules). Share with a group where you can. Then you change the group, not the rule.
How much. Read Only or Read/Write for most objects. On an account rule you also set access to the account’s contacts, opportunities and cases, where Private is an option. Full Access, which lets users “view, edit, transfer, delete, and share the record, just like the record’s owner,” is for campaigns only (same page).
And the hierarchy still applies to what the rule gives. “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 on (Sharing Rule Considerations). With a group as the target, the group’s own switch decides too (module 1).
Records owned by users without a role
Section titled “Records owned by users without a role”When you create a criteria-based rule, there’s another little checkbox with a side effect: Include records owned by users who can’t have an assigned role, such as high-volume users and system users. “This setting is enabled by default and can’t be edited after you save the rule” (Create Criteria-Based Sharing Rules).
It matters because most other ways can’t share these owners’ records. High-volume site users and Chatter users “can’t be included in owner-based sharing rules,” but “You can share records owned by high-volume users in guest user or criteria-based sharing rules” (Sharing Rule Considerations). If records are created by a site’s users or by a system user, a criteria-based rule may be the only rule that can share them.
One limit for older orgs: the option only exists on rules created after Spring ‘22. “To include these users in criteria-based sharing rules that were created before Spring ‘22, delete the rule and select Include records owned by users who can’t have an assigned role when you recreate it” (same page).
Some choices are final
Section titled “Some choices are final”For a criteria-based rule, “you can edit only the label, rule name, criteria filters, and sharing access level. If you must edit other fields, delete the rule and create a new one” (Create Criteria-Based Sharing Rules). And “After a sharing rule is saved, you can’t change the Share with field settings” (Sharing Rule Considerations).
So the target is final. Another reason to target a group: you can change who’s in it without touching the rule. If you target a role and later need a different one, you’re deleting the rule, which removes every row it wrote, and creating a new one, which writes them all again.
Two more limits on what you can do around a rule: “You can’t use Apex to create a criteria-based sharing rule. And you can’t test criteria-based sharing using Apex” (Sharing Rule Considerations). You test them as real users. Chapter 13 covers that.
Recalculation
Section titled “Recalculation”Every rule change is a recalculation. “After updates to sharing rules, sharing rules are recalculated to add or remove access as needed,” and it can take a while (Create Criteria-Based Sharing Rules). For big changes, Salesforce queues the work and sends you an email when it’s done (Sharing Rule Considerations).
One recent change helps. In Summer ‘26, “Salesforce is recalculating criteria-based sharing rules in parallel” after org-wide default changes, and you can watch the progress on the Background Jobs page in Setup (Jen’s Top Summer ‘26 Release Features for Admins (opens in a new tab), Salesforce Admins blog, checked 2026-11-07). For large changes, Salesforce still points to deferring sharing calculations, then recalculating later. Chapter 22 covers that.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video of a criteria-based rule from start to finish: a public group, a rule on the runways whose code contains a Z, and the rows it writes in the share table. 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 criteria-based rule: the source (the field and its value), the target and the access level, written down with the reason.
- Which field each rule reads, who can edit it, what automation fills it, and what a blank means.
- Record type labels, and their translations, unique where rules use them.
- The target: a group wherever you can, because the target can’t be changed after saving.
- Whether records owned by users without a role must be included, and which older rules need recreating to include them.
- When rule changes run, and whether big ones need deferred calculations.
Beyond the exam: what AI changes. A criteria-based rule shares on a field, and agents edit fields. An agent that updates a record’s region, status or department can move it into one rule and out of another, and change who sees it, in the same save. So list the fields your rules read, and check which agents can write to them. Salesforce’s Help also suggests using Setup with Agentforce to create rules (Create Criteria-Based Sharing Rules). Review the source, the target and the level before you accept one, because the target can’t be changed after saving.
Explore
Section titled “Explore”- Create Criteria-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)
- Sharing Rule Types (opens in a new tab), Salesforce Help (checked 2026-11-07): the field types you can share on
- Jen’s Top Summer ‘26 Release Features for Admins (opens in a new tab), Salesforce Admins blog (checked 2026-11-07): parallel recalculation of criteria-based rules