Asynchronous Sharing Recalculation After Group Membership or Role Changes

Overview

Salesforce is implementing enhancements to the sharing recalculation process to improve performance for large-scale transactions. After group deletion, group membership changes, or role updates occur, related owner-based sharing rules and account owner share records are recalculated asynchronously when that approach results in better performance. This document goes into detail about the changed behavior.

Note: This change is most relevant for customers who change the group or role membership of one or more users with a very high ownership data skew (for example, having a single user that owns hundreds of thousands of records of the same object).

If your org meets this criteria, the information in this knowledge article is relevant for your org.

Background

A share record (or sharing row on a share table) indicates the access that a user, group, or role has to a record. When group deletion, group membership changes, or roles updates occur, recalculations are triggered to make sure that share records are accurate and record access is up-to-date. Group membership or role changes result in these three steps:

Updates to group maintenance tables, which specify the membership data for all groups and roles, for both direct and indirect members.
(For changes to roles or role assignments only) Updates to account owner share records. Account owners can get default access to case, contact, and opportunity records depending on their role. When roles or role assignments are updated, these share records are also updated.
Recalculation of owner-based sharing rules. Owner-based sharing rules grant access to records owned by members of a group or role to members of other groups or roles. When a user, group, or role is added to a group or role that is the source of an owner-based sharing rule, sharing rows are created to represent this access. The reverse occurs when users, groups, or roles are removed from the source group or role.

Before, all three of these steps were executed synchronously and these operations blocked other processes until completion.

Updated Behavior

After group deletion, group membership changes, or role updates occur:

The group or role changes are processed synchronously (no change from current behavior).
Related owner-based sharing rules and account owner share records are recalculated asynchronously if the system determines that this yields better performance.

Whether asynchronous recalculation occurs is dynamic and depends on several factors, including record ownership of all impacted users, operational complexity, and database resource availability. Synchronous recalculations still occur when they’re determined to be more performant, which is usually the case. But when the system calculates that asynchronous recalculation is better in the case of a large transaction, this optimized approach allows for smoother operations and faster response times.

In the next sections, we look at three examples of how this asynchronous recalculation occurs after role or group changes.

Role Assignment

When you assign a user to a role, sharing rows must be updated so that access is correctly granted to that user, superiors in the role hierarchy, and users who have access via sharing rules. For example, you have a user in your org, Carole White, who has a very high ownership data skew because she owns more than 300,000 records of the same type. Carole doesn’t currently have a role. The role hierarchy currently looks like this:

CEO (Role)
- SVP of Technology (Role)
  - VP of Information Technology (Role)
- SVP of Business Operations (Role)

There’s also an existing sharing rule that shares records owned by users in the VP of Information Technology role with users in the SVP of Business Operations role. Carole is assigned the VP of Information Technology role. With Carole’s new role, the following access changes occur:

Users in roles above Carole’s VP of Information Technology role (SVP of Technology and CEO) gain access to the 300,000 records that she owns.
Users in the SVP of Business Operations role gain access to Carole’s 300,000 records via the sharing rule.
Carole gains access to records accessible to any roles below her in the role hierarchy or accessible via sharing rules that target her VP of Information Technology role.

Because of the scale of these changes and current system availability, it’s determined that it’s better to recalculate owner-based sharing rules asynchronously. The role assignment update is processed first, and the user can make other role changes immediately. Meanwhile, the sharing recalculation proceeds in the background.

Role Reparenting

Role reparenting is when you move a user or role that reports to one role to report to a different role. Let’s look back at the role hierarchy from the previous example:

CEO (Role)
- SVP of Technology (Role)
  - Jessica Jones (User)
  - VP of Information Technology (Role)
    - Carole White (User)
- SVP of Business Operations (Role)
  - Jim Baker (User)

You move the VP of Information Technology role (and the user Carole White) from under the SVP of Technology so that it instead reports to the SVP of Business Operations.

CEO (Role)
- SVP of Technology (Role)
  - Jessica Jones (User)
- SVP of Business Operations (Role)
  - Jim Baker (User)
  - VP of Information Technology (Role)
    - Carole White (User)

Sharing rows must be updated so that access is granted correctly through the role hierarchy and sharing rules. Users in the SVP of Technology role lose access to Carole’s records, while users in the SVP of Business Operations role gain access via the hierarchy. While these users in the SVP of Business Operations previously had access via the sharing rule, the sharing rows must be updated to reflect that their access now comes from the role hierarchy. Because of Carole’s high ownership data skew in addition to the complexity of the other changes, it’s better in this case to recalculate owner-based sharing rules asynchronously. The role change is processed immediately, and the sharing recalculation proceeds in the background asynchronously.

Group Membership Assignment

Group membership assignment (or unassignment) is when you add or remove a user or group to or from another group. For example, Carole White’s role now reports to the SVP of Business Operations role. However, the SVP of Technology still needs access to the accounts that Carole owns. You create a group, called Technology Users, then create an owner-based sharing rule where the source is the Technology Users public group and the target is the SVP of Technology role.

After you add Carole White to the Technology Users public group, owner-based sharing rules are recalculated to make sure access is up-to-date. We look at all the records she owns and share them with the SVP Technology role. Again, because of Carole’s high ownership data skew, it’s determined that it’s best to calculate the sharing rules asynchronously. The group membership change is processed immediately, and the sharing recalculation proceeds in the background asynchronously.

Required Updates to Apex Code and Flows

Note: Most group membership or role changes don’t lead to asynchronous sharing recalculation. However, if you meet the following criteria, it’s important that you review this section to avoid later issues with your Apex code and flows. Potentially impacted orgs:

Have large data volumes and a very high ownership data skew (for example, having a single user that owns hundreds of thousands of records of the same object).
Have Apex code or flows that modify group membership or roles.
Have Apex code or flows that rely on the immediate availability of updated share records after updates to groups or roles.

If you don’t meet the previous criteria, asynchronous sharing recalculation is less likely to occur in your org and impact your Apex code and flows. In this case, the steps in this section may not be necessary.

With asynchronous recalculation, share records aren’t updated immediately. If Apex classes, Apex tests, or flows rely on the immediate availability of updated share records after updates to groups or roles, the code or flows can break. For example, these scenarios can potentially have errors or changed behavior:

A SOQL query or assertion for share records with the row cause 'Rule' fails if it expects the records to be created immediately.
The System.runAs() method won’t reflect a user’s expected access until the asynchronous sharing recalculation is completed.

To prepare for this change:

Review the Update Apex Code and Flows for Changed Sharing Recalculation Behavior Salesforce release update in Setup for more information on this change and detailed steps on identifying and fixing impacted code and flows.
To identify impacted Apex code and flows, enable Test asynchronous sharing recalculation in Apex tests on the Sharing Settings page. Failing tests indicate that the code relies on synchronous sharing recalculation and requires updates.
Update the identified Apex code and flows so that they verify that share records, such as AccountShare records, are updated before proceeding.
After you’ve updated your Apex code and flows, disable Test asynchronous sharing recalculation in Apex tests to prevent false errors.
Test all changes in a sandbox before enabling the release update in production.

The release update was made available starting in Spring ’26 and will be enforced in Spring ’27. For more information, see the related release note.

Timeline

This change was introduced in Summer ’25 and rolled out over several releases. Salesforce completed the enablement of this updated behavior in all orgs in April 2026.

The one exception is for changes that originate from Apex code and flows, whose sharing recalculation continues to run synchronously until the Update Apex Code and Flows for Changed Sharing Recalculation Behavior release update is enforced in Spring ’27.

Monitor Recalculation Progress

Asynchronous Recalculation of Sharing Rules

Setup Audit Trail

When asynchronous recalculation of owner-based sharing rules occurs after group membership or role updates, you see three rows in the Setup Audit Trail. The first row (at the bottom of this image) indicates that the group membership or role updates have been processed synchronously. The next two rows indicate when the asynchronous recalculation of owner-based sharing rules is initiated and completed.

If the asynchronous recalculation fails after several attempts, an entry is logged in the Setup Audit Trail.

Background Jobs

When asynchronous recalculation of owner-based sharing rules occurs after group membership or role updates, the update is also logged on the Background Jobs page. The Job Sub Type is listed as “{Object} - Async Owner Sharing Rule Recalculation.”

Emails

The Salesforce admin that initiated the group membership or role update receives an email when asynchronous recalculation has started. The admin then receives an email after the recalculation completes successfully or an email if the recalculation fails after several attempts with details for contacting Salesforce Customer Support.

Synchronous Recalculation of Sharing Rules

If it’s more performant to recalculate owner-based sharing rules synchronously, as before, you see only one row in the Setup Audit Trail that indicates that both the group membership or role updates and sharing rule recalculation are completed.