Programmatic Sharing: Apex and Flow Managed Sharing

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

Chapters 6 to 10 were what Salesforce gives you: the defaults, the hierarchy, the rules, the hand tools and implicit sharing. This chapter is what you build. When none of those can see the thing that decides who gets a record, code or a flow inserts a row into the share table itself.

It used to be called Apex sharing. I call it programmatic sharing now, because flows do it too. And the most important thing I teach about it is when not to use it. The moment your code writes a share, you own everything the platform did for you before: new records, new users, owner changes, the rules changing, and the first day.

The ideas in this chapter

It’s the last tool, not the first. Walk the sets in order before writing a share. Try the hybrid first: code or a flow sets a field, and a criteria-based rule shares on it.
Code is justified when the declarative tools can’t see the decision. A parent or linked record, something about the user, more buckets than the rules allow, or rules kept in another system.
Watch your granularity. A share for every record for every person makes the share table the problem.
The row cause says why a share exists. Manual is removed when the owner changes. A sharing reason of your own is kept.
Standard objects can have their own reasons now. Since Winter ‘27, up to 10 per standard object, deployed through the Metadata API, and their shares survive an owner change.
Share with a bucket, not a person. A share can point at a group or a territory, and the people move in and out of the bucket instead of the share table.
Two doors into one piece of logic. A trigger or flow on the record, and one on the user, both calling the same share logic.
The user’s half needs its own transaction. User is a setup object, and a share isn’t, so they can’t be saved together.
Plan for the rules changing, and for day zero. A recalculation when the rules change, and a batch class or a bulk load for the first million records.
A flow can do all of it. The same share record, the same reason, the same two doors; only the tool changes, and its limits.

The picture

Here’s where the whole chapter starts: the questions before code.

Click to enlarge

Only after the sixth question does this chapter begin to write shares. And when it does, it builds one design, on one example: a custom object called Apple, a sharing reason called Party, and rules kept in custom metadata.

The path through this chapter

Six modules, each standing on its own.

Don’t Apex-Share Everything: When Programmatic Sharing Is Justified. The last tool, not the first; the questions before code; when code is justified; the hardware puzzle and the hybrid; the 100 million shares; where code can’t help.
The Share Record in Depth: Row Causes, Access Levels and Sharing Reasons. The share table and what isn’t in it; every row cause and who writes it; the green apple demo, Manual gone and Party kept; access levels, and which one wins.
Custom Row Causes on Standard Objects. Why code’s shares on accounts used to vanish on an owner change; what Winter ‘27 changed; how to create a reason on a standard object, its rules, and which of the two answers to use.
Share with a Bucket, Not a Person. One share per person or per bucket; how many buckets is too many; roles as targets once a portal arrives; four targets code can write; hidden territories as buckets.
The User Trigger and Day Zero. The trigger on the record and the trigger on the user; the user’s own transaction; code sketches of the whole design; recalculation; day zero; Spring ‘26’s asynchronous sharing.
Flow-Managed Sharing: The Same Share Record Without Code. The insert in a flow; who the flow runs as; the share logic as a subflow; the two doors in Flow; a scheduled recalculation; one bowl of limits; the bypass; flow or Apex.

Modules 5 and 6 are two builds of the same design, one in Apex and one in Flow.

Click to enlarge

Then check what stuck with the study guide.

What an architect decides here

For each sharing requirement, which set solves it, walked in order, and why code is needed if it is.
Whether a field set by code, plus a rule, can do the job instead of code writing shares.
The sharing reason, never Manual for code, and on a standard object, which of the Winter ‘27 answers the org uses.
The target: a person, a group or a territory, and how many share rows the design writes at today’s volume and at three times it.
Where the share logic lives, once, and the two doors that call it: the record and the user.
What recalculates the shares when the rules change, and how the first day’s shares get in.
Flow or Apex, by how busy the object is, who will maintain it and the volumes, with one entry point per object.
Who owns the sharing logic after go-live, since the platform no longer keeps it right.

Beyond the exam: what AI changes. Ask an AI assistant to make sure the right people see a record, and it will often write a share in code, on one door, with the Manual reason. It works on the first day. Ask it the review questions from this chapter: does a rule already do this, where’s the trigger on the user, what happens when the owner changes, what runs when the rules change, and how many rows will it write? And agents create users, change roles and transfer records. Each of those is a change your sharing logic has to hear. Chapter 20 covers agents.

Explore

Each module lists its own sources, each checked 2026-11-07. Two to start with:

Sharing a Record Using Apex (opens in a new tab), Apex Developer Guide, Winter ‘27 (checked 2026-11-07)
Recalculating Apex Managed Sharing (opens in a new tab), Apex Developer Guide, Winter ‘27 (checked 2026-11-07)

Next: Files, Folders, Reports and Other Data