Volume Meets the Sharing Model

🌐 Also in 19 languages

Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Image generated with AI

Module 3 of 4 in the chapter Designing for Scale, chapter 7 of the Data Architect course. Each module stands on its own. Previous: Hot Spots: Ownership, Parent and Lookup Skew · Next: If You’re Not Archiving Today…

The question this module answers: How does a model that respects sharing stay fast at volume?

The last module found the hot spots. Now add security, where a reasonable-looking data architecture gets expensive. Nine million work orders is a volume problem. Nine million work orders each visible to exactly the right internal users and exactly the right Retail Partner is a sharing-at-volume problem. A record isn’t just stored; Salesforce also has to answer who can see it? At scale, that answer is part of the data architecture.

Sharing Is Data Too

When architects count volume, they count business records. But Salesforce also maintains what supports access: owners, roles, groups, sharing rules, explicit shares, memberships. At small scale you can forget that work exists. At large scale you can’t. That’s why I never say “the security team will sort out sharing later.” The relationship I choose, the owner, the parent, the external-user model: each affects sharing. The data architect and the sharing architect may be different people, but their architectures are connected.

The Share Table Has Its Own Number of Zeros

Chapter 3 introduced the share table: the share object behind each object, AccountShare for Account, Truck__Share for a custom Truck__c, where Salesforce keeps most of the sharing for a record, one row per grant: which record, who, how much and why (Understanding Sharing (opens in a new tab); Sharing a Record Using Apex (opens in a new tab)). It’s an object of its own, with its own rows, and at volume that’s exactly the point. The share table has its own Number of Zeros.

Salesforce describes three kinds of tables behind record access. The object record tables hold the records and who owns each one. The object sharing tables, the __Share objects, “store each access grant in separate rows called sharing rows, each of which grants a user or group access to a particular record.” And the group maintenance tables store who belongs to each group, and the access people inherit through roles and groups (Record-Level Access: Under the Hood (opens in a new tab), Winter ‘27, archived copy (opens in a new tab)). When we talked about recalculation, this is where the work happens: rows being added and removed in those tables.

So do the math for the share table the way we did it for the records. Say each of Steve Trucking’s 9 million work orders is shared by three sharing rules: to its Retail Partner’s users, to its distribution center’s managers, and to an operations region. Work Order’s share object is WorkOrderShare, “a sharing entry on a work order” (WorkOrderShare (opens in a new tab)). That’s three of those rows per work order, about 27 million sharing rows behind 9 million records, before the owner’s own rows. Share the same records with individual users instead of groups, and the rows multiply by the number of people. The share table can be far bigger than the object it protects.

Click to enlarge

Step 1 of 3: the records. Nine million work orders.

Click to enlarge

Step 2 of 3: the share table, three rules to groups.

Click to enlarge

Step 3 of 3: the same access, shared person by person. Count the share table, not just the records.

That’s why the levers that keep sharing fast are mostly levers on the number of rows:

• Share with groups, not people. Salesforce’s own advice: grant access to the group instead of to the individuals, which “results in fewer sharing rows, thus reducing your organization’s record access data volume” (same source).
• A detail object has no share object at all. Its access comes from its master, so a master-detail child adds no sharing rows (chapter 3, and module 2’s Master-Detail at Volume for what that costs).
• High-volume community users don’t use sharing rows. They reach records through sharing sets instead, one of the reasons those licenses scale (chapter 3).
• Use a public default where the data isn’t confidential. A Public Read Only or Read/Write default needs no sharing rows to grant what everyone may already read (see Don’t Optimize Away Security, below).

Test knowledge. Know the share object (AccountShare, Object__Share): one row per grant, with a row cause; the three kinds of tables behind record access (object record, object sharing, group maintenance); and that sharing with groups rather than individuals means fewer sharing rows.

Start With the Access Requirement

I don’t start with which sharing feature to use. I start with who needs access to what? For Steve Trucking, one requirement is clear: each Retail Partner sees its own deliveries, never another’s. Simple to say. At scale I immediately want to know how many partner users there are, how many deliveries, how a delivery relates to its partner, who owns the delivery, and what happens when a user changes roles, a partner user is added or removed, or a partner relationship changes, and how often any of that happens. The access requirement comes first; then a model that supports it at the zeros we expect.

Ownership Drives Access

That’s why “who should own the delivery?” can’t be answered in isolation. If one integration user owns every work order, ingestion is easy, but if the business expected ownership to drive access, we’ve given up that way of controlling access. And if ownership doesn’t drive access, forcing millions of records through complicated ownership assignments adds complexity for nothing. So my rule for machine-created records applies here too: does ownership matter for sharing? If it does, ownership should reflect the access model. If it doesn’t, we have more freedom. One decision, made by the data architect and the sharing architect together.

The Role Hierarchy Isn’t an Org Chart

Teams design the role hierarchy to mirror the org chart. Then the company reorganizes, someone moves a role, and Salesforce has to work out the access consequences. At small scale nobody notices. At millions of records, reorganizing is a large data operation. That’s why the guidance for high-volume owners is to give them no role, or a separate, stable role at the top of the hierarchy (Ownership Data Skew (opens in a new tab)). The principle generalizes: at scale, stability is a design feature. The more records hang off a sharing structure, the more carefully you change it.

Groups are the same. Public groups feed sharing rules; users belong to groups; groups contain groups. Useful tools, but if huge populations of users and records depend on group membership that changes all the time, you need to understand the recalculation. That’s why high-volume owners stay out of public groups used as sharing-rule sources (same source). The lesson isn’t “public groups are bad.” It’s: don’t connect your biggest concentration of records to your most volatile access structures without thinking it through.

Sharing Recalculation Is Real Work

Steve Trucking changes its operating model: hundreds of users move, ownership changes, roles and groups change, a big sharing rule changes. It sounds like configuration. But the platform may have to recalculate access across a large population of records, so I treat it as a data operation. How many users, records, ownership and membership changes? How much recalculation? Can we test it at real volume? When should it run, and what do users see meanwhile? A large security realignment deserves the same discipline as a large data migration.

And don’t recalculate everything after every change. Making one change, waiting for everything to recalculate, then the next, then the next, rebuilds access over and over while the design is still moving. Salesforce’s answer for large realignments is deferred sharing calculations: prepare all the role, group and sharing-rule changes, apply them in a negotiated maintenance window, and let the recalculation run once (Deferred Sharing Maintenance (opens in a new tab)). Change, change, change, recalculate once. Two more of Salesforce’s suggestions keep the work down: process role hierarchy changes from the bottom (leaf) nodes up, “to avoid duplicate processing,” and remove redundant paths of access, “such as sharing rules that provide access to people who already have it through the hierarchy” (Designing Record Access for Enterprise Scale (opens in a new tab), Winter ‘27).

Test knowledge. Know the tools for large access changes: deferred sharing calculations (prepare every change, apply them in an agreed maintenance window modeled in a full copy sandbox, recalculate once) and granular locking, on by default, which lets unrelated role and group operations run at the same time.

Click to enlarge

At scale, access realignment is a data operation.

“Deferred” doesn’t mean casual. If a change is big enough to defer sharing, I want a plan: tested at realistic volume, a maintenance window the business agrees to, verification, a fallback if it doesn’t finish, and an understanding of what users experience during it. Salesforce’s guidance is to model it first in a full copy sandbox (same source), because a security model that works beautifully with 5,000 test records proves nothing about 50 million. Test the Number of Zeros you’re actually designing for.

Granular Locking Helps, but It Isn’t a Cure

Role and group updates lock the group-membership tables while they run, which used to make unrelated sharing operations collide. Granular locking, now on by default, lets unrelated group operations run at the same time (Group Membership Locking (opens in a new tab)); retry logic, serial processing, and scheduling separate group maintenance jobs so they don’t overlap help with what’s left. The idea is worth remembering: don’t lock more of the access structure than the operation needs. But don’t conclude “locking is solved.” Granular locking reduces some contention. It doesn’t rescue a poor ownership model, a volatile hierarchy, or an access design that constantly forces massive recalculation. Platform features help; architecture still matters.

Steve Trucking: Partner Isolation at Scale

At Checkpoint 1, every work order carries its Retail Partner, durably, because partner isolation is a requirement. The scale numbers make that more important, not less: if Redrock is 40% of the business, that’s about 3.6 million Redrock work orders over five years. The relationship is right; Redrock really is one partner. So the access design has to follow the real business relationship (partner users seeing their partner’s work orders, DC managers only their DC’s) rather than distorting the model. The child-account-per-DC structure from the last module helps here twice: it spreads the children, and it gives DC-level access a real thing to hang on.

And keep authorization separate from identity. At the checkpoint we decided not to unify Recipients across partners, precisely because a shared identity is exactly the kind of link that can expose one partner’s data to another. Even where identity resolution is used inside one partner, it answers who might this person be? Sharing answers who may see this record? Blur them, and at this scale the mistake isn’t wrong once. It’s wrong millions of times.

Internal Access Is Different Again

Partners are only part of it. Coordinators, crews, care agents, operations, finance and sales need different things. A care agent may need broad visibility to answer “where’s my delivery?”; a crew only today’s stops, and the Recipient’s details only on the day; operations a region; finance the money, not every operational detail; sales the partner, not the Recipients. The Sharing and Visibility course goes through Steve’s 25 Ways to Share a Record; I won’t reproduce it here. The data architect’s job is to recognize that the model either enables those choices or constrains them.

Sometimes security should change the model. When two kinds of information have completely different owners, lifecycles, audiences or sharing needs, you can pile field-level controls onto one record, or split the data into its own object with its own boundary. I don’t split just to avoid configuring field-level security, but security is a legitimate reason to change the physical model.

Sharing Has Its Own Number of Zeros

Two designs with 10 million records each: one with simple ownership, a stable hierarchy, few sharing rules and little membership churn; the other with highly distributed ownership, frequently changing roles, large nested groups, many sharing rules and constant reorganization. Same record count, completely different scale problem. So for every high-volume object, I want the access model’s numbers too: how many owners and how concentrated, the default access, which hierarchy relationships, rules and groups matter, how many external users, and what happens when someone changes role, a partner is added, or a region is reorganized. Then one question: what’s the biggest recalculation this design could cause? That’s the scenario I want tested.

Click to enlarge

Count the access model, not just the records.

Don’t Optimize Away Security

There’s a dangerous conclusion to avoid: sharing is expensive, so make everything public. No. Performance isn’t an excuse to abandon a security requirement. Salesforce’s own guidance draws the line in the right place: “Use a Public Read Only or Read/Write organization-wide default sharing model for all non-confidential data” (same guide). Non-confidential data can be public; confidential data stays protected, and the design has to carry it. The job is an architecture that satisfies both: simpler ownership, more stable hierarchies, better group design, splitting data with different security needs, different relationships, planned realignments. “Private is slower, so make it public” is not an architecture strategy.

Beyond the exam: what AI changes. Agents retrieve and aggregate faster than any person, which makes an overly broad access model more dangerous. Don’t rely on a prompt saying “don’t show Brightwave’s data to Redrock.” The boundary belongs in the architecture: authorization should limit what an agent can reach, not instructions what it chooses to reveal. Scale the authorization model with the data model.

What an Architect Decides Here

• Which relationships, owners, roles, groups and sharing rules drive access for each high-volume object.
• Whether high-volume owners and other hot spots are isolated from volatile hierarchy and group structures.
• How large access realignments are tested, scheduled, recalculated once and verified at production volume.
• Whether different security needs justify splitting data rather than complicating access to one record.
• How partner, employee, application and agent access stays tied to business relationships, not identity shortcuts.

It’s easy to draw a secure design for 1,000 records, and a fast one where everyone sees everything. The architect’s job is the system where both survive: the right people see the right data, and it still works when we add the zeros. At scale, sharing is part of the data architecture.

Explore

• Object Reference for the Salesforce Platform, WorkOrderShare (opens in a new tab) (Winter ‘27), checked 2026-11-01.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Takeaway: Tuning Group Membership for Performance (opens in a new tab) (Winter ‘27): leaf-first hierarchy changes and removing redundant access paths, checked 2026-11-01.
• Salesforce Developers, Designing Record Access for Enterprise Scale (Winter ‘27): Ownership Data Skew (opens in a new tab), Group Membership Locking (opens in a new tab) and Deferred Sharing Maintenance (opens in a new tab), checked 2026-11-01.
• For depth: the Sharing and Visibility Architect course, Sharing at Scale (coming soon).
• SteveTechArc, Salesforce Documents by Release: these guides, once a year from Winter ‘16, each with an archived copy.
• Salesforce, Record-Level Access: Under the Hood (opens in a new tab) (Winter ‘27, archived copy (opens in a new tab)), checked 2026-10-20.
• Apex Developer Guide, Understanding Sharing (opens in a new tab) and Sharing a Record Using Apex (opens in a new tab), checked 2026-11-01.