Steve Trucking's Internal Users, What I Would Architect

Checkpoint 1 of Securing Salesforce: Sharing and Visibility, at the end of chapter 10, Overrides and Implicit Sharing: What You Get for Free. It puts chapters 6 to 10 together on one scenario.

The question this checkpoint answers: Can you build an internal sharing model from the defaults up, and say what the platform adds on its own?

Try the challenge first. This is my walkthrough of Checkpoint 1’s challenge. If you haven’t drawn your own design yet, do that before you read on. The value is in comparing your reasoning with mine, not in reading the answer.

This is “What I Would Architect”: a possible viable solution, not the answer, with the trade-offs named and my positions taken. It’s only Steve Trucking’s own staff. The Retail Partners’ users, the crews and the Recipients come later.

Start with the defaults

Chapter 6 said it: the org-wide default is how locked each file cabinet starts, and you set it for the most restricted user, then open up (Org-Wide Defaults). So, object by object, internal access:

Account: Public Read Only. Twelve partner accounts today, three Retail Partners and nine DCs. Every employee may know who the partners are and where the DCs are. Nothing in the account itself is secret.
Contact: Controlled by Parent. These are the partners’ DC managers and store staff. They follow their account, so every employee can read them, and nobody has to think about them again.
Opportunity: Private. Contract renewals and new DC bids. Pricing for one partner (S2) is exactly what sales keeps to sales.
Case: Private. Recipient questions carry personal data (S4), and partner claims carry money.
Work Order, Work Order Line Item, Service Appointment: Private. This is the one people miss. Salesforce’s own page says that when you install the Field Service managed package, these defaults are set to “Public Read/Write,” and that “most Field Service customers choose to limit access” (Limit Access to Field Service Records (opens in a new tab), Salesforce Help, checked 2026-11-07). Every delivery has a Recipient’s name, phone and home address on it. Public Read/Write would show a million homes a year to every employee.
Manifest__c: Private. A partner’s daily list is its volume, and volume is in S2.

Then make one check before you go on: a standard user, nothing shared, sees accounts and contacts and nothing else. Prove the negative first.

The coordinators: their own DC

Now challenge SV2. A coordinator works inside one Retail Partner’s DC. Should they see the other DCs? The other partners?

Think about where they sit. A Steve Trucking coordinator at the Keystone DC in Dallas sits on Keystone’s dock, at a screen that Keystone’s staff walk past all day. If that screen can show Redrock’s deliveries, the S2 boundary is only as strong as the coordinator’s habits. And what does the job need? Routes for this DC, trucks for this DC, exceptions for this DC (R10, RP3).

Option A: every coordinator sees every DC. Easy cover when someone’s out, one shared pool. But each coordinator then carries three partners’ Recipients and volumes into another partner’s building.

Option B: each coordinator sees only their own DC, and cover is granted on purpose. In my professional opinion, B. Need to know, and the screen in Keystone’s building only knows Keystone.

How to build B? You might reach for the role hierarchy, or a rule per DC. Field Service already has the answer, built for exactly this person, the dispatcher. Turn on User Territories sharing, and “When a service territory is created, a Public Group is created in Setup with its name,” and each service appointment in that territory is shared with that group. Then a User Territory record adds a dispatcher to the territory’s group, and “the user gets access to all work orders, service appointments, service resources, and any other records shared with the public group” (Limit Access to Field Service Records).

So each DC is a service territory, each territory has its group, and each coordinator has one User Territory record: their DC. When someone covers the Phoenix DC for a week, they get a second User Territory record, and it’s removed when the week is over. A public group from chapter 7, made and filled for you (Public Groups).

Two catches from the same page, and both are design rules:

Give dispatchers Read/Write. If you write your own sharing logic, “ensure that every dispatcher gets Read/Write access and not just Read-Only access,” or they can’t edit the crews’ schedules.
Don’t change the owner. “When you change the owner of a shared object, sharing of this object is removed for the service territory public group.” That’s chapter 9’s lesson on what survives an owner change (What Survives an Owner Change), on a delivery.

And notice what this is. It isn’t declarative sharing. It’s the Field Service package writing shares for you, which is programmatic sharing (chapter 11). You configure it; you still test it.

The role hierarchy: for access, not as an org chart

Chapter 6’s rule: each role stands for a level of data access, not a job title (The Role Hierarchy). Here’s the tree I’d draw:

Leadership at the top.
Operations, and under it a regional manager role for each region, Phoenix, Dallas and Atlanta, with that region’s coordinators below.
Customer care manager, with the care agents below.
Finance and back office, its own branch.
Sales, with the account managers below.

Why a role for each region, when the coordinators’ deliveries come from the territories? Because of what they own. A case a coordinator logs, a note, a record they create, rolls up to their regional manager, and not to the other two.

And the integration users? No role at all. Each Retail Partner’s integration creates every Work Order for that partner, hundreds of thousands a year. Chapter 6 gave Salesforce’s line for an owner like that: “The user record of the owner should not hold a role in the role hierarchy” (Ownership and Queues). Ownership skew, a performance problem (chapter 22).

But see what that costs. With no role, nobody is above the owner. The role hierarchy gives leadership nothing on the deliveries. That’s fine. It’s why the next section exists.

Click to enlarge

Who owns what

Ownership is the first key (chapter 6). Four decisions:

Work Orders: the partner’s integration user, and they stay that way. Changing owners would strip the territory shares.
DC accounts: the regional manager for that region. That’s on purpose, for the implicit sharing below.
Retail Partner accounts: the sales account manager for that partner.
Cases: a care queue first, then the agent who works it.

The groups, rules and teams

Now open up only what the territories don’t.

Customer care, finance and leadership read every delivery. Recipients call Steve Trucking, not the partner, so care has to find any delivery for any partner. Finance invoices every partner. Leadership reports on all of it (RP2). One owner-based rule, chapter 8’s vacuum cleaner (Owner-Based Sharing Rules): Work Orders owned by the group of integration users, shared Read Only with a group of care, finance and leadership. One rule, and it doesn’t grow when a DC does.
Care agents work each other’s cases. One owner-based rule on Case: owned by the care roles, shared Read/Write with the care group.
The manifests. Manifest__c is custom, so no Field Service sharing and no implicit sharing reaches it (module 6). One criteria-based rule per DC: DC equals this DC, shared with that territory’s public group. Nine rules today.
The account managers. A Keystone account manager owns the Keystone account. Does that show them the claims logged against the three Keystone DC accounts? No, and module 6 said why. So they’re on an account team on each of their partner’s DC accounts, with Read on cases (chapter 9, Teams).
No territories. Enterprise Territory Management shares accounts and their special children. Accounts here are already Public Read Only, and the deliveries aren’t account children at all. It would add a second hierarchy for nothing (chapter 9, module 4).

Count the rules: two owner-based, nine criteria-based. Now Steve Trucking wins its tenth DC. The service territory is created, so its group is created with it. The coordinators get User Territory records. The owner-based rules don’t change. One thing grows: a tenth manifest rule. Three times the volume could mean nearly three times the DCs, and every one is another rule on the same object. That’s Steve’s Number of Zeros at work (How Many Buckets?): watch the one series that grows. In Checkpoint 2, after chapter 11, I replace it with a share written in a flow (Checkpoint 2: Build It, Then Prove It).

What the data model shares on its own

This is the chapter’s question, on a real design. Have your implicits in mind.

Where Salesforce opens records by itself:

Contacts follow their account. Controlled by Parent, so every employee reads the partners’ staff (chapter 6, module 6).
The regional manager sees the cases on their DC accounts. They own the DC accounts, so child implicit sharing opens the cases at whatever their role’s Case Access says (module 3). I set it to View. That’s how a regional manager sees every claim at their three DCs, with no rule.
The account manager sees other people’s opportunities on their partner’s account, at their role’s Opportunity Access. I set it to View, so a renewal someone else is working is visible to the person who owns the relationship.
Anyone who sees a case or an opportunity reads its account. Parent implicit sharing, Read Only (module 2). Here it adds nothing, because accounts are Public Read Only, but it’s still writing rows. Know it’s there.
Field Service shares the parents too. When a service appointment is shared with a territory’s group, “associated parent records (such as accounts, assets, opportunities, work orders, and work order line items) are also shared” (Limit Access to Field Service Records), and you choose which in Field Service Settings. I keep Share parent Work Order on, and turn Share parent Account off: accounts are already readable, and that’s rows nobody needs.
The overrides. Only the admins hold View All Data or Modify All Data. Nobody gets View All Records on Work Order, not even finance; the owner-based rule does that job and shows up in the sharing model, where an auditor will look for it. Run module 1’s two queries to prove it.

Where people will expect it, and it isn’t there:

Owning a DC account doesn’t open its deliveries. Work Orders aren’t one of the special account children (module 6). The regional manager sees the region’s deliveries through their own User Territory records, one for each DC, not through the account.
Owning the Retail Partner account doesn’t open the DC accounts’ children. Account hierarchies don’t share (module 6). That’s the account team above.
Nothing reaches Manifest__c by itself. It’s custom.
Leadership gets nothing from the hierarchy on deliveries. The owners have no role. That’s the owner-based rule.

Click to enlarge

The option I didn’t choose

The obvious alternative is the one Field Service gives you on day one: Work Orders and appointments left Public Read/Write, a role per DC, and everyone trusted to look only at their own. It’s quick, and nobody ever calls to say they can’t see a delivery.

But that design hands every employee a million Recipients’ home addresses a year, puts three partners’ volumes on a screen in each partner’s building, and leaves nothing to take away when someone moves. I don’t choose that design.

In my professional opinion

The requirement is: each of Steve Trucking’s own people sees the deliveries, cases and deals their job needs, and coordinators inside a partner’s DC see that DC only.

My solution is: private deliveries, appointments, cases, opportunities and manifests; coordinators and regional managers through Field Service’s User Territories; a role hierarchy built for what people own, with the integration users outside it; two owner-based rules, a manifest rule per DC, and account teams on the DC accounts; and implicit sharing used on purpose, through the role’s child access on the accounts the regional managers and account managers own.

The reason is: the boundary follows the DC, the structure the business already has, so a new DC is mostly a new territory, not a new design.

The option I didn’t choose was the day-one Public Read/Write with trust.

In my professional opinion, the best internal sharing model is the one where you can name, for every record, the reason each person can see it. Checkpoint 2 builds this and proves it with real users.

Explore

Limit Access to Field Service Records (opens in a new tab), Salesforce Help (checked 2026-11-07)
Steve Trucking brief