Skip to content

Study guide

Study guide for chapter 11 of the Securing Salesforce: Sharing and Visibility course. Read the six modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter teaches one objective from the exam’s biggest section, Access to Records (39% of the exam): programmatic sharing. The exam guide also lists implementing programmatic sharing as an area where candidates are likely to need help. The exam guide aligns to Winter ‘23, and a lot has changed here since then, so those changes are in their own list at the end. Know both, and know which date each belongs to.

Tick them off as you go. Each one links to where it’s taught.

When to use it (supports REC-7)

  • I can walk the questions before code, in order, and say why each earlier set doesn’t solve the requirement. (The questions before code)
  • I know when code is justified: a decision based on a parent or linked record, on the user, more buckets than the rules allow, or rules kept in another system. (When code is justified)
  • I know the hybrid: code or a flow sets a field, and a criteria-based rule shares on it. (Try the hybrid first)
  • I know a detail object in a master-detail relationship has no share object, so its sharing comes from the master. (Where code can’t help)

The share record (supports REC-7)

  • I know the share table holds most sharing but not all of it: not the role hierarchy, not View All or Modify All. (The share table)
  • I know the row causes, who writes each, and that code can write only Manual or a reason of its own. (The row cause)
  • I know a share written with Manual is removed when the owner changes, and one with an Apex sharing reason is kept. (Watch it go)
  • I know only users with Modify All Data can add or change Apex managed sharing. (Watch it go)
  • I know the access levels, that code can’t grant All, that the most permissive level wins, and that a share at or below the default isn’t needed. (Access levels)

Targets (supports REC-7, and REC-4 for groups)

  • I know a share can point at a user, a public group, a role group or a territory group, and why a bucket writes fewer rows than a share per person. (One share per person, or one per bucket?)
  • I know that after digital experiences are enabled, a share to Roles and Subordinates also reaches portal users, and Salesforce’s advice is Roles and Internal Subordinates. (Roles as targets)
  • I know four targets code can write: a person, a group, a team member and a territory. (Four targets code can write)

Keeping shares right (supports REC-7)

  • I know programmatic sharing needs logic in two places: on the record being shared, and on the user. (Is that the only trigger you need?)
  • I know the User object is a setup object, so the user’s shares need their own transaction to avoid a mixed DML error. (The user trigger needs its own transaction)
  • I know recalculation is batch Apex (Database.Batchable), and on a custom object the class goes in the Apex Sharing Recalculation related list, which also runs it when the org-wide default changes. (Recalculation)
  • I know the two ways to load day-zero shares: let a batch class write them, or bulk load the share records. (Day zero)

In a flow (supports REC-7)

  • I know a flow writes a share with Create Records on the share object, with the same four pieces. (The same insert, in a flow)
  • I know record-triggered and schedule-triggered flows run in system context without sharing by default, and flows from a button or a page run as the user. (Who is the flow)
  • I know a flow on User writes its shares on an asynchronous path, or through a platform event, to avoid mixed DML. (The two doors)

What changed since the exam’s Winter ‘23 alignment (dated, beyond the exam today)

  • I know that since Winter ‘27 (API version 68.0), standard objects with a share object can have up to 10 custom sharing reasons, deployed through the Metadata API, and their shares are kept on an owner change. (What changed)
  • I know that before that, code on a standard object could only use Manual, and the fix was a trigger on the owner change. (The question that sent me to an org)
  • I know Winter ‘27 also added an org setting to keep manual shares when records are transferred, and when to use it instead of a reason of your own. (Which of the two to use)
  • I know the Spring ‘26 release update makes role and group changes recalculate in the background, enforced from Spring ‘27, so access can arrive a little later. (Spring ‘26)

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

  • Don’t Apex-share everything. Walk the sets first, and try the hybrid.
  • Watch your granularity. Count the share rows at today’s volume and at three times it.
  • Never write code shares with Manual when a reason of your own is available.
  • Share with a bucket when the same people need the same records.
  • In every review, ask two questions: where’s the trigger on the record, and where’s the trigger on the user?
  • Write the share logic once, and call it from every door: the record, the user and the recalculation.
  • Delete only the shares your logic wrote, filtered on your own reason.
  • Build the bypass before the load, not the day before.
  • One entry point per object: a flow or a trigger, not both.
  • Test with real users, not by counting rows. An insert can update an existing row instead of adding one.
TermIn one line
Programmatic sharingCode, a flow or an integration inserting rows into the share table
Share tableThe table beside an object that holds its shares, such as AccountShare or Apple__Share
Row causeWhy a share row exists: Owner, Rule, Manual, Team, or a reason of your own
Apex sharing reasonA custom row cause; shares with one are kept when the owner changes
Trivial shareA share that grants no more than the org-wide default already does; refused
BucketA group or territory used as a share’s target, so people move instead of shares
Hidden territoryA territory branch used only as a sharing target, not for sales
Setup objectAn object such as User or Group that can’t be saved with ordinary records in one transaction
Mixed DML errorThe error when setup and non-setup records are saved in the same transaction
RecalculationA batch job that rebuilds the shares when the rules change
Day zeroThe first load of records and their shares, before anyone logs in
Asynchronous pathA part of a record-triggered flow that runs after the save, in its own transaction
BypassA switch, such as a custom permission, that turns automation off for a load

Short scenarios in the style of the course. Decide your answer before you open it.

1. A US opportunity that contains a hardware item must be shared with the VP of Hardware and their subordinates. Does this need code that writes shares?

Not necessarily. A criteria-based rule can’t read the line items, but code or a flow can set a field on the opportunity, Has Hardware, when a line item is added. Then a criteria-based rule shares on it. Code that keeps a field right is easier to live with than code that keeps shares right. Reread Try the hybrid first.

2. Code shares a custom object's records with the Manual row cause. After the owner changes, the users lose access. What's the fix?

Create an Apex sharing reason on the object and write the shares with it. Shares with a reason of your own are kept when the owner changes; Manual ones are removed. Reread Watch it go: the green apple.

3. Code writes a share for every account for each of 2,000 sales users in a region. What would you ask?

How many rows that writes, and whether a bucket would do. Share each account once with a group or a hidden territory for the region, and move the users in and out of the bucket instead. Reread One share per person, or one per bucket?.

4. A trigger shares apples with users based on rules in custom metadata. A new user joins and sees no apples. Why?

The trigger is on the apple, and nothing on an apple changed. Programmatic sharing needs logic on the user too, calling the same share logic, in its own transaction because User is a setup object. Reread Is that the only trigger you need?.

5. A trigger on User inserts share records directly, and fails. What's the error, and what are the fixes?

A mixed DML error: User is a setup object, and a share record isn’t, so they can’t be saved in the same transaction. Hand the share work to its own transaction: a queueable job or a future method in Apex, or an asynchronous path or a platform event in a flow. Reread The user trigger needs its own transaction.

6. Someone changes the sharing rules in custom metadata. No record or user changed. What brings the shares up to date?

A recalculation: a batch that deletes the shares with your reason and writes what the rules say now. On a custom object, the Apex class goes in the Apex Sharing Recalculation related list. In a flow, a schedule-triggered flow, within its limits. Reread When the rules change: recalculation.

7. You go live with a million accounts and about 10 shares each. What are the two ways to get the shares in, and what do you build first?

Let a batch class write them, which can take hours or days, or work them out ahead and bulk load the share records, which is faster but must match the triggers’ logic. Either way, build the bypass first, so the sharing flows and triggers don’t fire during the load. Reread Day zero and Day zero: build the bypass first.

8. A record-triggered flow creates share records for users who can't see the record themselves. Is that a bug?

No, that’s how it works: a record-triggered flow runs in system context without sharing by default, so it can see every record and write a share to anyone. That’s the point, and the risk, so every flow that writes or deletes shares needs a reviewer. Reread Who is the flow when it writes the share?.

The official list of objectives and their weights. Always check the current version before you book an exam.