Owner-Based Rules, Reorganizations and Recalculation

Module 4 of 4 in the chapter Owner-Based Sharing Rules, chapter 8 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: An owner-based rule depends on who owns what and who’s in which role or group. So what does it cost when those change, and how do you change them safely?

Here’s a question for the room. An admin moves one sales rep from the region 1 role to the region 2 role. One field on one user record. How much work is that for Salesforce?

It depends on what that rep owns, and on every rule that uses either role. Salesforce’s own guide says it plainly: “seemingly simple changes to groups and group membership can sometimes involve substantial recalculations of users’ access rights” (Group Membership Operations and Sharing Recalculation (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers, Winter ‘27 edition, checked 2026-11-07).

What changes the shares

Module 1 listed what makes Salesforce re-evaluate a sharing rule. For an owner-based rule, every one of them is a change to people or ownership (Sharing Rule Considerations (opens in a new tab), Salesforce Help, checked 2026-11-07):

A transfer. “When you transfer records from one user to another, the sharing rules are reevaluated to add or remove access to the transferred records as necessary.”
A change of membership. “When you modify which users are in a group, role, or territory, the sharing rules are reevaluated to add or remove access as necessary.”
A change to the rule. A new access level updates every record the rule shares. Deleting the rule removes the access it created.

Remember what’s behind each rule: rows in the share table, one per record per group (chapter 7, module 2). A re-evaluation is Salesforce writing and deleting those rows. The more records the people own, the more rows move.

Moving one user

Here’s what Salesforce does when one user moves to another branch of the role hierarchy (Group Membership Operations and Sharing Recalculation):

The hierarchy. “the managers in the branch above the user’s old role lose access to all the data that the user owns,” and “Managers in the branch above the user’s new role gain access to the user’s accounts and to child records according to their own role settings.”
The rules. “Salesforce also recalculates all sharing rules that include the user’s old or new role in the source group.” The user’s records leave the rules whose source is the old role, and join the rules whose source is the new one.
The rules that no longer fit. “Some sharing rules might no longer be valid given the user’s new location in the hierarchy, in which case an administrator might need to modify or delete them.”

That’s the vacuum cleaner working in reverse. The rule picks up whatever the source owns. Move the owner out of the source, and everything they own goes with them. If they own customer or partner accounts, there’s more work still: their external account roles move too (chapter 14).

Click to enlarge

Moving a whole role

Moving a role, not a person, has one benefit: customer and partner accounts “simply move along with their parent role, and Salesforce doesn’t have to change the related sharing.” But Salesforce does all the work of moving one user for every user in that role, and for all their data (same page).

So a reorganization isn’t one change. It’s the one-user work, times every user, times everything they own, times every rule that uses those roles or groups as its source.

Big owners in a source group

Chapter 6, module 3 introduced ownership skew. Salesforce’s guide defines it as “when a single user owns more than 10,000 records of an object,” and names the moment it hurts: when those users are “moved around the hierarchy, or moved in to or out of a role or group that is the source group for a sharing rule.” Then Salesforce must adjust a very large number of rows in the sharing tables, and the recalculation can run for a long time (Ownership Data Skew (opens in a new tab), Designing Record Access for Enterprise Scale, Winter ‘27 edition, checked 2026-11-07).

That’s this chapter’s rule exactly. An integration user, a placeholder owner for unassigned leads, an agent’s user: if one of them is in your source group, every change to that group drags all their records with it. Salesforce’s advice for those users, if they must have a role: “Keep them out of public groups that can be used as the source for sharing rules” (same page).

Locks

Changes to roles and groups also take turns. “The sharing system locks the tables holding group membership information during updates.” Usually the locks are brief, but “In some scenarios—such as a change in role triggering a sharing rule recalculation—locks can be held for a longer time, and conflicts can occur.” Then someone sees “could not acquire lock” or “Group membership operation already in progress” and has to try again (Group Membership Locking (opens in a new tab), Designing Record Access for Enterprise Scale, Winter ‘27 edition, checked 2026-11-07).

When does it happen? Salesforce names the moment: “periodic organizational realignment events, such as end-of-year or end-of-quarter processing, where many account assignments and user roles are changing.” That’s exactly when the business is least patient. Granular locking is on by default and lets unrelated groups change at the same time, but “reparenting (moving roles within the role hierarchy), still block almost all other group updates” (same page).

Habits for big changes

Salesforce’s guide gives a list. These are the ones that matter most for owner-based rules (Takeaway: Tuning Group Membership for Performance (opens in a new tab); Group Membership Locking; Designing Record Access for Enterprise Scale, Winter ‘27 edition, checked 2026-11-07):

Rehearse. “Always test substantial configuration changes in a full copy sandbox that’s been recently refreshed so you know what to expect in production.”
Go bottom up. “When making changes to the hierarchy, process changes to the bottom (leaf) nodes first, then move upward to avoid duplicate processing.”
Spread ownership. “Limit the number of records of an object owned by a single user to 10,000.”
Remove what’s redundant. “Remove redundant paths of access, such as sharing rules that provide access to people who already have it through the hierarchy.” Every redundant rule is rows to move in the next reorganization.
Pick the time. “Schedule large group membership operations during off-peak hours,” schedule separate group maintenance jobs so they don’t overlap, and run batch operations in serial mode.
Expect to retry. Build “retry logic in integrations and other automated group maintenance processes to recover from a failure to acquire a lock.”

For the biggest realignments, Salesforce lets you suspend sharing calculations, “specifically for sharing rules and group membership, then resume calculations during an organization’s maintenance period” (Tools for Large-Scale Realignments (opens in a new tab), Designing Record Access for Enterprise Scale, Winter ‘27 edition, checked 2026-11-07). Chapter 22 covers deferring calculations and sharing at scale.

Click to enlarge

What an architect decides here

Which roles and groups are the source of owner-based rules, so every reorganization starts with that list.
Who owns the most records of each object, and that those users stay out of source groups, or out of roles, as Salesforce advises.
How reorganizations run: rehearsed in a recently refreshed full copy sandbox, bottom up, off-peak, in serial, with retries, and with deferred calculations for the biggest.
Which rules give access people already have through the hierarchy, and removing them.
After each reorganization, which owner-based rules no longer fit, and who changes or deletes them.

Beyond the exam: what AI changes. Agents will be asked to do reorganizations: “move these 40 reps to the new region.” To the agent, that’s 40 field updates. To the sharing model, it’s every record those reps own, through every rule whose source includes either role, while other jobs wait on the locks. Before an agent changes roles or groups in bulk, ask it the same questions you’d ask a person: what do these users own, which rules use these roles, and when should this run? Chapter 20 covers agents.

Explore

Group Membership Operations and Sharing Recalculation (opens in a new tab), Designing Record Access for Enterprise Scale, Salesforce Developers, Winter ‘27 edition (checked 2026-11-07)
Ownership Data Skew (opens in a new tab), same guide (checked 2026-11-07)
Group Membership Locking (opens in a new tab), same guide (checked 2026-11-07)
Takeaway: Tuning Group Membership for Performance (opens in a new tab), same guide (checked 2026-11-07)
Tools for Large-Scale Realignments (opens in a new tab), same guide (checked 2026-11-07)
Sharing Rule Considerations (opens in a new tab), Salesforce Help (checked 2026-11-07)