Skip to content
SteveTechArcSteveTechArc Courses

Public Groups and Criteria-Based Sharing Rules

Chapter 7 of Securing Salesforce: Sharing and Visibility, Part 2: The File Cabinets: Sharing Records. New to the course? Start with chapter 1.

Chapter 6 locked the file cabinets: the org-wide defaults, the owner, the role hierarchy. Now we start opening them up. And the first thing I teach is this: there is a superpower in here, and it is called a public group.

A public group is a bucket, a named list of who. Point a sharing rule at the bucket, and when the people change, you change the bucket, not the rule. Then the rule itself: a criteria-based sharing rule is studying the record. If the record has a value in a field, share it. This chapter is those two tools, used together, and the traps that come with them.

The ideas in this chapter

Section titled “The ideas in this chapter”
  • A bucket grants nothing. A public group has no records of its own; it’s a target you point rules, shares, folders and list views at.
  • One rule, one group, then change the group. Who sees the records changes with the group’s membership, and every change is a sharing change.
  • Every rule has three parts. The source, the target and the level: what you share, with whom, and how much.
  • The field you share on is a security control. Who edits it, what fills it, and what a blank means decide who sees the record.
  • A guest rule reaches the whole internet. Anything it matches, anyone can read, so keep guest rules off your core business records.
  • Count the buckets before you build. 50 criteria-based or guest rules per object, 300 in all, and one budget for every team.
  • Share on a meaning, never an ID. An ID belongs to one org, so the rule breaks when it moves.
  • A shared list view shares the filter, never the records.

The picture

Section titled “The picture”

Here’s where the chapter starts: one rule, one group, and the group does the changing.

One rule, one group One rule, one group. A sharing rule targets a single public group. Drawn as a tree: the group at the top, and inside it a few named users, a role, a role and internal subordinates, and an all-US group, which holds an Arizona, a California and a Nevada group. Next month, another group is added, and its people get access without anyone touching the rule. Footnote: change who sees the records by changing the group, and every change is a sharing change. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-10-31", "id": "DGM-SVA-GR-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "tree 0.1.0", "theme": "stevetecharc 1.4.0"} A public group one sharing rule targets it A few named users every move is a change A role everyone in that role A role and internal subordinates the people who do the work An all-US group groups inside a group Arizona group California group Nevada group Next month: another group access without touching the rule Change who sees the records by changing the group. Every change is a sharing change. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

And the three parts of every sharing rule you write.

The three parts of a sharing rule The three parts of a sharing rule. One, the source: what am I sharing? The records that match a field value, for example job applications where Department is IT. Two, the target: who am I sharing it with? A public group, a role, a role and internal subordinates, or a territory, for example the IT managers group. Three, the level: how much access? Read Only or Read/Write, for example Read Only. Footnote: source, target, level; write all three down with the reason. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.57.1", "built": "2026-11-01", "id": "DGM-SVA-GR-14", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} 1. The source what am I sharing? The records that match a field value Example: job applications where Department is IT 2. The target who am I sharing it with? A public group, a role, a role and internal subordinates, or a territory Example: the IT managers group 3. The level how much access? Read Only or Read/Write Example: Read Only Source, target, level. Write all three down with the reason. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The path through this chapter

Section titled “The path through this chapter”

Six modules, each standing on its own.

  1. Public Groups: The Swiss Army Knife of Sharing. A bucket grants nothing; what goes in it; one rule, one group; the group’s own hierarchy switch; keeping buckets healthy; personal groups and manager groups.
  2. Criteria-Based Sharing Rules: Sharing by What’s on the Record. The three parts; what happens when you save; designing the field you share on; targets and levels; records owned by users without a role; the choices that are final; recalculation.
  3. Guest User Sharing Rules: The Rule That Reaches the Public. The only way in, Read Only; Salesforce’s warning; keeping guest rules off core records; the two locks; criteria for the public; records guests create.
  4. How Many Buckets? Sharing Rule Limits and Steve’s Number of Zeros. The limits; what about Guam?; the number of zeros for sharing; fewer buckets first; when the zeros outgrow rules.
  5. Never Hard-Code IDs in Sharing Rules, and How Rules Sprawl. How an ID gets in; why it doesn’t travel; what the deployment carries; what to share on instead; how rules sprawl, and the habits that stop it.
  6. Sharing a List View Doesn’t Share the Records. What a list view shares; who you can share it with; three permissions; the list view bleed.

Then check what stuck with the study guide.

What an architect decides here

Section titled “What an architect decides here”
  • The buckets the org needs, named for the access they stand for, with as few named users in them as possible, and who may change each one.
  • For each group, whether Grant Access Using Hierarchies is on, and why.
  • For each criteria-based rule, its source, target and level, written down with the reason, and a group as the target wherever you can.
  • For each field a rule reads, who can edit it, what automation fills it, and what a blank means.
  • Which objects guest rules may touch, and the explicit field that marks what anyone may read.
  • For each object, how many of the 50 and the 300 rules it uses, and the number of zeros before a new request is built as rules.
  • That no rule shares on a record ID, and the naming and description every rule gets.
  • Who may share list views, and with which groups.

Beyond the exam: what AI changes. Salesforce’s Help now suggests asking the Setup agent to create groups and sharing rules. That’s a sharing change made by a sentence. Ask it to share each account with its state’s team, and it may build one rule per state, or use an ID, because an ID is the easiest thing for it to see. Before you accept what an agent builds, read the source, the target and the level, count what’s left of the 50, and check what the bucket opens. Chapter 20 covers agents.

Explore

Section titled “Explore”

Each module lists its own sources. Two to start with:

Next: Owner-Based Sharing Rules

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.