Hey there,
I was reading the
on asynchronous sharing recalculation after group membership or role changes (the one about high ownership skew). It only talks about users who own hundreds of thousands of records, and it never mentions queues.
My thinking is that queues probably aren't affected. A queue has no role or profile and isn't a user. But queue membership changes do update the same group tables, and a queue can own a huge number of records, so I can't rule it out.
Has anyone tested this or heard it confirmed? If you've changed membership on a big queue, did you see the async recalculation show up in the Setup Audit Trail or under Background Jobs?
I'm trying to figure out if our Apex tests and flows that touch queue membership need a look.
Thanks!
Mit
@Mit Chandola The KB article you read focuses on User Ownership Skew. When a User owns more than 10,000 records, their position in the sharing architecture is heavily embedded in the platform's security model. If that User changes Roles or is moved in/out of a Public Group, Salesforce must re-evaluate the sharing access for every single record they own. Because the Role Hierarchy or Owner-Based Sharing Rules might now dictate that entirely different branches of the company should (or shouldn't) see those 10,000+ records, Salesforce pushes this massive row-level update to an asynchronous background job to prevent system lockups.
Queues operate completely differently under the hood:
- No Roles: Queues do not sit in the Role Hierarchy.
- No Public Group Memberships: Queues cannot be placed inside Public Groups for the sake of Owner-Based Sharing Rules.
- Pointer-Based Access: When a Queue owns 500,000 records, the internal [Object]Share tables do not write individual rows for every user in the queue. They simply write one pointer per record where the UserOrGroupId equals the Queue's ID.
When your Flow or Apex adds a user to a queue, Salesforce only inserts a single row into the GroupMember table. The sharing engine dynamically looks at this table at runtime to determine who has access to the queue's contents.
Because the underlying [Object]Share rows for the records are never actually modified or re-evaluated, there is no massive recalculation required. The group maintenance is handled synchronously and nearly instantly. You will not see an async job pop up in the Background Jobs or Setup Audit Trail for this action.
While you don't have to worry about asynchronous sharing recalculation, you should still keep an eye out for Group Membership Skew. If your Apex or Flow is trying to add or remove members from a queue that contains tens of thousands of nested users or public groups, you could hit synchronous CPU time limits or UNABLE_TO_LOCK_ROW errors on the Group or GroupMember tables.
As long as your queue memberships are relatively normal in size, your current automation does not need to be refactored to account for async delays.
