Build It, Then Prove It

Checkpoint 2 of Securing Salesforce: Sharing and Visibility, at the end of chapter 13, Testing the Security Model. It puts chapters 11 to 13 on Checkpoint 1’s design.

The question this checkpoint answers: Can you finish an internal sharing model with code, flows and files, and then prove it, persona by persona?

Try the challenge first. This is my walkthrough of Checkpoint 2’s challenge. If you haven’t written your own design and test plan, do that before you read on.

This is “What I Would Architect”: a possible viable solution, not the answer. Checkpoint 1 built the model with the tools you click. This checkpoint adds three things, then does what Checkpoint 1 promised: proves it with real users. It’s still only Steve Trucking’s own staff.

1. One rule per Retail Partner

Each partner’s account managers need that partner’s deliveries, in all three of its DCs, and never another partner’s (S2).

Option A: a rule per DC. Nine today, one more with every DC.

Option B: a rule per partner. Three today. A new DC doesn’t add one; only a new partner does.

In my professional opinion, B, because the boundary is the partner, and the partner count grows slowly. A group per partner, Keystone Account Team, Redrock Account Team and Brightwave Account Team, with that partner’s account managers in it. One criteria-based rule each on Work Order: this partner’s deliveries, Read Only, to this partner’s group.

Here’s the catch that chapter 7 taught. The partner is on the Work Order’s account, a lookup, and a criteria-based rule can’t read through it: “In criteria-based sharing rules, you can’t use lookup fields” (Criteria-based rules). So the Work Order gets a plain text field, Partner Code, and the integration fills it from the partner’s key when it creates the delivery. No exact field? Add one, and fill it with an automation.

Count the rules on Work Order now: one owner-based rule from Checkpoint 1, three criteria-based. Nowhere near 50 or 300.

2. The manifests, shared in a flow

Checkpoint 1 left the manifests on a criteria-based rule per DC, and flagged that series as the one that grows. Chapter 11 gives the other answer.

Option A: keep a rule per DC. Nine today, perhaps 25 or more at three times the volume. Simple, declarative, and a new rule every time a DC opens.

Option B: write the share in a flow. When a manifest is created or its DC changes, a record-triggered flow writes a share on Manifest__Share for the public group Field Service already made for that DC’s service territory, with a sharing reason of our own, Territory.

In my professional opinion, B. Look at what it reuses. The target is a bucket that already exists, the same territory group that opens the DC’s deliveries (share with a bucket). Coordinators move in and out of the group through their User Territory records, so the shares never move. That’s why this design needs only one door, the record: the user’s door is the group, and Field Service keeps it.

The rest is chapter 11’s list (flow-managed sharing):

• The reason. Territory, created on Manifest__c in Salesforce Classic, because on a custom object that’s still where sharing reasons are made. Never Manual, so the share survives an owner change.
• Who the flow runs as. A record-triggered flow runs in system context, so it can see every manifest and write the share.
• The rules changing. If a DC moves to another territory, the same flow rebuilds that DC’s manifest shares.
• Day zero. Today’s manifests get their shares from a one-time load, with the bypass on.

3. Photos and claim files

About four photos a delivery, four to five million a year, and some show the inside of a home or people (S5). Chapter 12 asked two questions of every cabinet (the other cabinets): who can open it, and whose access fills it?

• Delivery photos live on the Work Order and its service appointment, where the crew takes them. A file on a record is visible to anyone who can see the record, unless it’s Private on Records (on a record). That’s the design I want: the photo follows the delivery, so the coordinators of that DC, care and finance see it, and nobody else does.
• Claim files live on the claim’s case. Care sees them; the account team sees them through the account team on the DC account, from Checkpoint 1.
• Close the other doors. No libraries for photos or claims. Nobody internal gets Create Public Links for them; a link anyone can forward is the widest door in chapter 12. The Recipient’s photo link (R7) is a design of its own, in Checkpoint 3.

That’s a deliberate trade-off. Finance reads every delivery, so finance can open its photos. If that’s too much for S5, the fix is finance’s access to deliveries, not the photos’.

The test plan

Now the part this chapter is for. Module 2’s table, written before anyone logs in, with module 1’s three users for every requirement and module 4’s evidence for every row.

Click to enlarge

First, the null test. A standard internal user, with no role, no group and no User Territory, opens Work Orders, service appointments and manifests. They see none. If they see one, something is open that the design didn’t open, and every test below would pass for the wrong reason.

Then the rows. Each “Expected” was written from the design; each “Evidence” says what goes in the plan beside it.

Persona	Check	Expected	Evidence
Coordinator, Keystone Dallas	A Keystone Dallas delivery	Can view and edit the schedule	Sharing Hierarchy: the territory’s group
Coordinator, Keystone Dallas	A Keystone Phoenix delivery	Can’t see	UserRecordAccess: no read
Coordinator, Keystone Dallas	A Redrock Dallas delivery	Can’t see	UserRecordAccess: no read
Coordinator covering Phoenix	A Keystone Phoenix delivery, during and after the cover	Sees it during; not after the second User Territory is removed	UserRecordAccess, run twice
Regional manager, Dallas	Deliveries at all three Dallas DCs	Can view	Sharing Hierarchy: the three territory groups
Regional manager, Dallas	A Phoenix delivery	Can’t see	UserRecordAccess: no read
Keystone account manager	Keystone deliveries in Phoenix, Dallas and Atlanta	Can view, not edit	Sharing Hierarchy: the Keystone rule
Keystone account manager	A Redrock delivery	Can’t see	UserRecordAccess: no read
Care agent	Any delivery, any partner	Can view, not edit	Sharing Hierarchy: the owner-based rule
Coordinator, Keystone Dallas	The Keystone Dallas manifest	Can view	Share table: a Territory row for the group
Coordinator, Redrock Dallas	The Keystone Dallas manifest	Can’t see	Run-as test, negative
Coordinator, Redrock Dallas	A photo on a Keystone Dallas delivery	Can’t open	Tested as the user
Any internal user	A public link to a delivery photo	None exists, and they can’t make one	View Summary: no Create Public Links

Three things to notice about how each group is proved.

The coordinators are mostly Field Service’s sharing. That’s code we didn’t write, so the test is the only proof we have. The Sharing Hierarchy shows the reason; UserRecordAccess checks the negatives across a page of records at once.

The partner rule can’t be tested in Apex. Salesforce says it plainly: “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 (opens in a new tab), Salesforce Help, checked 2026-11-07). So it’s proved as real users, in their own sessions, and the evidence is the Sharing Hierarchy’s reason.

The manifest flow can. It’s our code, so it gets module 3’s run-as tests: create a manifest for Keystone Dallas, run as a Keystone Dallas coordinator and expect it, run as a Redrock Dallas coordinator and expect nothing. Those run on every deployment.

What reruns the tests

Module 1 said a model that passes on day one can fail on day ten. Here’s when Steve Trucking’s tests run again:

• A new DC. The territory and its group are created, coordinators get User Territory records, and the manifest flow shares to the new group without a change. Rerun the coordinator rows and the manifest rows for that DC.
• A new Retail Partner. A new group and a fourth rule. Rerun every partner row, both ways: the new partner’s team sees only theirs, and nobody else’s changed.
• A delivery changes owner. It shouldn’t, ever: “When you change the owner of a shared object, sharing of this object is removed for the service territory public group” (Checkpoint 1). Keep a test that fails if any automation changes a Work Order’s owner.
• A coordinator moves DC. Rerun their rows. And since Spring ‘26, role and group changes can be recalculated in the background, so a test that moves someone may need to wait before it checks (access arrives a little later).
• Any release that touches sharing. The run-as tests run on their own. The people’s rows run before go-live.

In my professional opinion

The requirement is: finish Steve Trucking’s internal model, and prove that every one of its own people sees what their job needs and nothing more.

My solution is: one criteria-based rule per Retail Partner, on a field the integration fills; the manifests shared in a flow to the territory groups Field Service already keeps; photos and claim files left on their records, with every other door closed; and a test plan, written before anyone logs in, that proves every persona with three users and records the evidence beside each row.

The reason is: each piece reuses a boundary the business already has, the partner and the DC, so the next DC or the next partner is a row in the plan, not a new design.

The option I didn’t choose was a rule per DC for everything: fine at nine, and a list nobody can keep right at twenty-five.

In my professional opinion, a sharing model isn’t finished when it’s built. It’s finished when you can show, for every persona, the test that proves it and the evidence beside it. Checkpoint 3 opens the door to the people outside: the Retail Partners’ users, the crews and the Recipients.

Explore

• Sharing Rule Considerations (opens in a new tab), Salesforce Help (checked 2026-11-07)
• Steve Trucking brief