The Sharing Model Your Data Model Must Respect

The question this module answers: Which records can each person see, and what in the data model decides it?

Into the File Cabinets

In module 1 we got into the office: structural security, the apps, objects and fields a person can use. Now the file cabinets. You’ve made it into the HR office, but that doesn’t mean you should see every file. Of all the Work Orders at Steve Trucking, which ones can Redrock’s DC manager open? Which can a crew see? Which can care staff see?

That’s record-level security, and it’s where the data model and the security model meet head on. The exam objective says it directly: design a data model that respects the security and sharing model. You can’t respect a model you don’t know. So this module is the short version of what I teach in a whole Sharing and Visibility course, cut down to what a data architect has to design around. Two reminders from module 1 hold all the way through: where structural and record-level security disagree, the most restrictive wins, and the one structural setting that overrides record-level security is View All or Modify All, which skip sharing entirely. Use them sparingly.

Start Private if Even One Person Mustn’t See It

Every object starts with an org-wide default: the baseline access everyone gets before any sharing is added. Public Read/Write means everyone who can see the object can see and edit every record. Public Read Only means everyone can see every record. Private means you see only what you own, or what’s shared with you. And there’s a fourth, Controlled by Parent, which we’ll come to.

My rule when I set org-wide defaults: if there’s even a single user in your system who mustn’t see a record, even one human being, dial it down to private. Set it at the most restrictive level you might possibly need, because it’s easier to open up later than to lock it down later. Opening up is adding a rule. Locking down, after a year of people seeing everything, is a change in how people do their jobs, and somebody always discovers they relied on what you just took away.

Steve Trucking’s Work Orders are an easy call. Redrock must never see Brightwave’s deliveries, pricing, volumes or Recipients. So Work Orders are private, and so is everything that carries a partner’s data. Then we open up, deliberately, layer by layer.

When the default is private and nothing else is added, who sees a record? The owner, and only the owner. That’s the foundation everything else builds on. Each mechanism in this module opens a little more, until the last one, which takes some away.

Click to enlarge

Test knowledge. Know the org-wide defaults (Private, Public Read Only, Public Read/Write, Controlled by Parent) and that they set the baseline before any sharing is added. Under a private default, a record is visible to its owner, to users above the owner in the role hierarchy (when Grant Access Using Hierarchies is on), and to users with View All or Modify All, which bypass sharing. Where object permissions and record access differ, the most restrictive applies.

Parents Decide for Their Children

Module 1 said relationships are security architecture. Here’s where that becomes concrete.

A master-detail child has no access of its own. Its org-wide default is Controlled by Parent: if you can see the master, you can see the detail. That’s why a Work Order Line Item needs no sharing design at all. It follows its Work Order, which is exactly right, because a line item means nothing outside its delivery. A lookup child, by contrast, keeps its own owner and its own sharing, which is what we wanted for the Crew Member HR Record in module 1.

The account family is special. Accounts, contacts, opportunities, cases, orders, contracts: these standard objects live in their own world, and if you try to categorize them like custom objects, your head will explode. Salesforce maintains implicit sharing between an account and its children:

• Parent: a user who can see a child case, contact or opportunity gets read-only access to its parent account. Salesforce’s own example: Henry sees an opportunity through a sharing rule, “He can view data about the opportunity’s parent account, but he can’t edit the account’s data.”
• Child: the owner of an account gets access to its child cases, contacts and opportunities, controlled by the child access settings on the owner’s role.

Salesforce also notes that the parent share is “expensive to maintain with many account children,” because when a user loses access to one child, it has to check all the others. That’s chapter 7’s account skew showing up again from the security side. Three Retail Partner Accounts with millions of children is a sharing problem as well as a locking problem.

Notice what isn’t on that list: Work Orders. Field Service’s Work Order looks up to an Account, but it doesn’t get the account family’s implicit sharing. Seeing Redrock’s Account doesn’t open Redrock’s Work Orders. We have to design that access ourselves, and that’s a good thing, because it means nothing opens by accident.

Test knowledge. Know that a master-detail child’s org-wide default is Controlled by Parent, so access follows the master, while a lookup child has its own owner and sharing. Know implicit sharing in the account family: access to a child case, contact or opportunity gives read-only access to the parent account; the account owner gets access to its children through the role’s child access settings. Implicit sharing isn’t used when the child is controlled by its parent.

The Role Hierarchy Is a Security Decision

The role hierarchy opens records upward: whoever is above the owner in the hierarchy gets the owner’s access. Not the manager field on the user. The role. And for standard objects that’s always on; only on custom objects can you turn off Grant Access Using Hierarchies.

So ask the question I ask every class. A care agent at Steve Trucking owns a case. Who can see it? The care agent, and everyone above the care agent: the care team lead, the director of customer care, the vice president of operations, all the way to the top.

Now: what if that case is a complaint, and the complaint is about the vice president of operations? Does the vice president get to see the case? Right now, they do. And not just complaints. Anything personal that lands in a case: a crew member’s medical leave, a divorce that changes their benefits. The vice president types a name into global search and finds it.

Click to enlarge

If you want to keep confidential records out of normal visibility, they have to be rooted in their own branch of the tree, from the top of the hierarchy, or owned by a user with no role. So the first place I look, when there’s confidential data, is the top of the hierarchy: whoever is there sees everything that rolls up to them. Then I look at who’s going to own the confidential records, which branch they’re in, and what’s at the top of that branch. That’s a data architecture decision as much as a security one, because it decides who owns what.

This is also why the role hierarchy isn’t an org chart. Chapter 7 made that point for scale: reorganizing a hierarchy that millions of records hang off is a large data operation. This is the same lesson from the other side. The role hierarchy is a map of who should see whose records, not a copy of who reports to whom.

Open Up With Groups and Sharing Rules

From private, we open up. And the superpower in here is the public group.

A public group can contain users, but it can also contain roles, roles and their subordinates, territories, and other groups. Groups contain groups contain groups. So instead of sharing a record with a list of people, you share it with a group, and then you manage the group. Next month, add a new team to the group, and they get access, without touching a single sharing rule.

Sharing rules are how we open records to groups and roles automatically. Each one has three parts: what am I sharing, who am I sharing it with, and what access am I giving them, read only or read/write. An owner-based rule shares the records owned by one set of users with another. A criteria-based rule looks at the record itself: if a field on the record matches, share it.

At Steve Trucking, every Work Order carries its Retail Partner, because we made that relationship durable at Checkpoint 1 precisely for this. So the partner rules are simple:

• A group for each Retail Partner’s users: Keystone, Redrock, Brightwave.
• One criteria-based rule per partner: if the Work Order’s Retail Partner is Redrock, share it read-only with the Redrock group.

Three partners, three rules. Clean. Now the business asks for more: each Retail Partner’s DC manager should see only their own DC’s deliveries.

Click to enlarge

Sharing Rules Have a Number of Zeros Too

This is where I stop and ask the question I always ask about sharing rules: how many will there be?

The obvious design is one criteria-based rule per DC. Nine DCs today: nine rules. But Steve Trucking grows about 30% a year. New DCs open. A new Retail Partner signs. Every one of those is another rule. In class I describe it with US states: someone builds one criteria-based rule per state, Arizona, Nevada, California. You can quickly see where that goes. Salesforce allows up to 300 sharing rules per object, but only up to 50 of them can be criteria-based or guest user rules. Fifty states, fifty rules: the normal cases use up the whole limit.

Then somebody asks, what about Guam? Or the business brings another requirement on the same object that needs its own criteria-based rule. There’s no room left. The pattern has consumed the limit with the normal cases and left nothing for the exceptions and variances every business has. That isn’t a sustainable pattern, and you can see it coming before you build the first rule.

Steve Trucking has the same shape. Nine of fifty sounds safe today. But every new DC takes another rule, every new partner requirement takes another, and the room for the next real exception shrinks every year. There’s a cost while you wait, too: criteria-based rules look at the record, so Salesforce checks them every time the record is saved; they add work to every insert and update. So anytime a pattern heads past about ten rules, I’d say don’t. Watch around 10 or 15, because 10 becomes 20 or 30.

What do we do instead? Look for the structure that’s already in the data. If the Work Order knows its DC, and each DC’s users are in a group, then groups nested inside each partner’s group, or a DC level in the account structure the partner’s users sit under, can carry the DC boundary without a rule per DC. Chapter 7 suggested a child account per DC for skew; it gives DC-level access something real to hang on, too. Module 5, the checkpoint, makes the full design. For now, the habit: when a sharing rule is one of a series, ask what the series will look like at year five.

And one more trap from real orgs: sharing rules with hard-coded IDs, share-with-this-one-user. They can’t be deployed. Created in production, they only work in production, so your test environments stop behaving like production. Share with groups and roles, never with an ID.

Test knowledge. Know the sharing-rule types (owner-based and criteria-based, plus guest user rules for unauthenticated users) and the limits: up to 300 sharing rules per object, including up to 50 criteria-based or guest user rules. Know that public groups can contain users, roles, roles and subordinates, territories and other groups, so one rule targeting a group can grow without new rules.

Restriction Rules Take Access Away

Everything so far opens access. Restriction rules do the opposite. They run after all the sharing, and they narrow what a user can see to the records that match the rule: for example, users in support see only the contracts flagged for support.

That’s real power. Sharing can only add access; a restriction rule is the one declarative way to take it back after everything else has opened it. But it’s a very limited capability, limited in how many you get and in which objects you can use it on.

How many first. Salesforce allows “up to two active restriction rules per object in Enterprise and Developer Editions and up to five active restriction rules per object in Performance and Unlimited Editions.” In class I call it the double-barreled shotgun: two shots. Use them up on today’s requirement, and they aren’t there when a harder one arrives next year. So spend them carefully, on the requirement nothing else can meet. A restriction rule on a parent “doesn’t automatically restrict access to its child objects.” They don’t apply to code running in system mode, or to users with View All or Modify All.

Then which objects. They’re available only on certain objects: custom objects, external objects, contracts, events, quotes, tasks, and time sheets and their entries. Look at what’s missing for Steve Trucking: Work Orders and Cases. You can’t use a restriction rule to hide one partner’s deliveries, or to hide the confidential complaint. Those have to be designed with the tools above. A restriction rule could narrow a custom object like the Manifest, if we needed it to. That’s a good example of why the data architect needs to know which objects support which mechanism: the object you choose decides the security tools you get.

Test knowledge. Know that restriction rules narrow access after sharing; that orgs get 2 active rules per object (Enterprise, Developer) or 5 (Performance, Unlimited); that they’re available for custom objects, external objects, contracts, events, quotes, tasks, time sheets and time sheet entries; that a rule on a parent doesn’t restrict its children; and that system mode and View All / Modify All aren’t restricted.

People Outside the Company

Retail Partner users work in Steve Trucking’s partner portal, an Experience Cloud site. External users bring one more design decision, and it’s made with the license, before any sharing rule.

I describe the external licenses as stadium seats:

• Customer Community is the cheap seats at the back, built for very large numbers of users. These are high-volume users, and in Salesforce’s words they “don’t have roles, which eliminates performance issues associated with role hierarchy calculations”. You can’t put them in public groups or owner-based sharing rules (About High-Volume Community or Site Users (opens in a new tab), checked 2026-10-29). The ways in are sharing sets, which grant access to records related to the user’s account or contact, and share groups, which share the records high-volume users own back with internal users.
• Customer Community Plus is the middle of the stadium, with cushions: roles and sharing, so sharing rules, groups and manual shares all work, plus reports and dashboards.
• Partner Community is the best external seats, just above the plaza where the internal users sit: roles and sharing like Customer Community Plus, plus the sales objects, leads and opportunities, for partners who sell with you.

Click to enlarge

For Steve Trucking’s Retail Partner users, the requirement is roles and sharing rules, because their access follows the partner and the DC, not their own account or contact. That’s Customer Community Plus or Partner Community, the decision we recorded at Checkpoint 1. Recipients get no license at all: the tracking link shows one delivery through a token, without a login. That’s module 5’s design.

When would sharing sets matter? Here’s a labelled what-if. If Steve Trucking someday let Recipients log in to see their own deliveries, there could be hundreds of thousands of them. That’s a high-volume population: no roles, no sharing rules, so a sharing set would give each Recipient the deliveries tied to their own contact. The license you pick decides the sharing tools you have, so pick it with the access model in hand.

Test knowledge. Know that high-volume external users (such as Customer Community) have no roles and can’t be in public groups or owner-based sharing rules, so they get record access through sharing sets (records related to their account or contact) and their records are shared back through share groups; Customer Community Plus and Partner Community users have roles and sharing, so sharing rules and groups apply.

Prove It With Three Users

How do you know any of this works? You test it, and you need three users to do it properly: one who owns the record (or an administrator), one you’re sharing with, and one you’re not sharing with. Prove the positive share, and prove the negative. That’s the bare minimum to test any security mechanism.

Click to enlarge

At Steve Trucking: a Work Order owned by the integration user. Log in as a Redrock DC manager: you see it. Log in as a Brightwave DC manager: you don’t. The second test is the one teams forget, and it’s the one that matters most, because partner isolation is a promise that someone can’t see something. A test that only shows that the right person sees the record proves half the requirement.

The Other Ways to Share

I’ve covered the mechanisms a data architect designs the model around. There are more: manual sharing, account, opportunity and case teams, territory management, Apex and flow-based sharing, guest user rules, and others. In the Sharing and Visibility course I teach them as Steve’s 25 Ways to Share a Record. You don’t need all 25 to design a data model. You need to know they exist, and that each one depends on something in the model: an owner, a role, a relationship, a field the rule can read.

Beyond the exam: what AI changes. An agent that runs as the logged-in user gets exactly that user’s record access, including everything a loose sharing rule or a too-tall role hierarchy lets them see, and it finds it faster than they ever would. A tight sharing model is now an AI control too. Module 4 goes into who an agent runs as.

What an Architect Decides Here

• The org-wide default for each object, at the most restrictive level anyone might need.
• Which relationships inherit access (master-detail, the account family) and which need their own sharing.
• Who owns each kind of record, and where those owners sit in the role hierarchy, especially for confidential records.
• Which groups and rules open access, and how many there will be at year five.
• Which objects support which mechanisms, such as restriction rules, before choosing the object.
• Which external licenses fit the access model, and how it will be tested, positive and negative.

The Model Decides What Sharing Can Do

Every mechanism in this module reads something in the data model: an owner, a role above the owner, a parent, a field a rule can test, an account a sharing set can follow. If the Work Order didn’t carry its Retail Partner, no sharing rule could enforce partner isolation. If confidential cases were owned by people deep in the operations branch, no amount of rules could keep them from the top of that branch. That’s why the data architect can’t hand security to someone else after the model is done.

Start private. Open up deliberately, with groups and rules you can count. Take away only where the platform allows it. And prove it with someone who should see the record, and someone who shouldn’t.

Explore

• Salesforce Help: Sharing Rules (opens in a new tab) (types and limits), checked 2026-11-01.
• Salesforce, Designing Record Access for Enterprise Scale: Implicit Sharing (opens in a new tab), checked 2026-11-01.
• Salesforce, Restriction Rules Developer Guide: Considerations (opens in a new tab), checked 2026-11-01.
• Salesforce Help: About High-Volume Community or Site Users (opens in a new tab), checked 2026-11-01.
• Salesforce Architects: Platform Sharing Architecture (opens in a new tab), checked 2026-11-01.
• Trailhead: Create a Role Hierarchy (opens in a new tab), checked 2026-11-01.
• Chapter 7, Volume Meets the Sharing Model: the scale side of everything in this module.