This is the part 2 of Sharing and Visibility Designer Exam. Declarative Sharing section weighs 7% of total score in this exam, that is roughly 4 questions that might be come out from this section. Even though that is considerably small portion of the exam, but who knows that might be what you need for passing the exam? So, better get prepared for this section too!

NOTE: This post is written in April 2020 and content might be changed/updated overtime. The content is inspired by focusonforce.com.

Guideline for Performance and Scalability

  • Given a particular complex customer org setup, design a security model that is maintainable at large scale.

Group Membership and Sharing Recalculation

  • Salesforce Role Hierarchy, Public Groups, and Territories are closely connected to Sharing Rules.
  • Changes to groups and group membership can sometimes involve substantial recalculations of users' access rights, especially when there is complex organization setups and large amount of data to be processed.
  • Some used cases:
    • when a user is moved from one branch of the role hierarchy to another, Salesforce performs these actions to ensure other users have correct access to data owned by that relocated user:
      • add/remove access to the user's data for people who are above the user's role in hierarchy
      • add/remove access to related contacts, cases and opportunities
      • recalculates all sharing rules that include the user's old and new role in the group
    • when a role is moved from one branch to another
      • no change to related sharing, just move along with their parent role
      • Salesforce must do all of the work in moving a single user for all users in the role being moved and for all of those users' data
    • when the owner of a portal account is changed
      • Salesforce moves the portal roles to a new parent role
      • adjusts the sharing for all the data associated with the portal account
  • List of operations that can occur in parallel:
User provisioning User role change Role insertion Role deletion Role reparenting Territory creation Territory insertion Territory deletion Territory reparenting Addition of user to territory Removal of user from territory Any group membership operation
Role creation ✅ ✅ ❌ ❌ ❌ ✅ ❌ ✅ ✅ ✅ ✅ ❌
Role deletion ❌ ❌ ❌ ❌ ❌ ❌ ✅ ✅ ✅ ✅ ✅ ❌
Role reparenting (includes change of portal account owner) ❌ ❌ ❌ ❌ ❌ ✅ ❌ ❌ ❌ ❌ ❌ ❌
Adding user to territory ✅ ❌ ✅ ✅ ❌ ✅ ❌ ❌ ❌ ✅ ❌ ❌
Removing user from territory ✅ ❌ ✅ ✅ ❌ ✅ ❌ ❌ ❌ ❌ ❌ ❌
Territory reparenting ✅ ❌ ✅ ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
Territory deletion ✅ ❌ ✅ ✅ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌
Territory creation ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ ✅ ✅ ❌
Provisioning internal user with an existing role ✅ ✅ ✅ ❌ ❌ ✅ ❌ ✅ ✅ ✅ ✅ ❌
Changing user role (User must not own any portal accounts.) ✅ ❌ ✅ ❌ ❌ ❌ ✅ ❌ ❌ ❌ ❌ ❌
Provisioning first non-Community portal user under an account ✅ ✅ ❌ ❌ ❌ ✅ ❌ ✅ ✅ ✅ ✅ ❌
Creating second non-Community portal user under an account ✅ ✅ ✅ ❌ ❌ ✅ ❌ ✅ ✅ ✅ ✅ ❌
Provisioning Community user ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✅
Changing portal account owner ❌ ❌ ❌ ❌ ❌ ✅ ❌ ❌ ❌ ❌ ❌ ❌
Changing role of a user who owns a portal account ❌ ❌ ❌ ❌ ❌ ✅ ❌ ❌ ❌ ❌ ❌ ❌
  • Some Group Membership tuning suggestions:
    • identify user and group updates that are complex, allowing additional time to process changes
    • when making changes to the hierarchy, always process changes to the bottom one first, then moving upward to avoid duplicate processing
    • limit number of records of an object owned by a single user to 10,000
    • experimenting with batch sizes and using bulk API whenever possible
    • remove redundant sharing rules and etc.
  • Types of Implicit Sharing:
    • Parent
      • Read Only access to the parent account for a user with access to a child record
      • Not used when sharing on the child is Controlled by Parent
      • Expensive to maintain with many account children
      • When a user loses access to a child, Salesforce needs to check all other children to see if it can delete the implicit parent
    • Child
      • Access to child records for the owner of the parent account
      • Not used when sharing on the child is Controlled by Parent
      • Controlled by child access settings for the account owner's role
      • Supports account sharing rules that grant child record access
      • Supports account team access based on team settings
      • When a user loses access to the parent, Salesforce needs to remove all the implicit children for that user
    • Portal
      • Access to portal account and all associated contacts for all portal users under that account
      • Shared to the lowest role under the portal account
    • High Volume
      • Access to data owned by high volume users associated with a Sharing Set for users member of the Sharing Set's access group
      • All members of the Sharing Set access group gain access to every record owned by every high volume user associated with that Sharing Set
    • High Volume Parent
      • Read Only access to the parent account of records shared through a Sharing Set's access group for users member of the group
      • Maintains the ability to see the parent account when users are given access to account children owned by high volume users

Performance Measures for Large-Scale Realignment

Parallel Sharing Rule Recalculation

  • When a sharing rule change affects access rights to a very large amount of data, recalculation of sharing rules can take a long time and a recalculation job can get killed before completion.
  • Normally, when an administrator creates, deletes, or edits a sharing rule, the recalculation required to make those changes take effect is processed synchronously. The same is also true when sharing rules are recalculated because of updates, such as a movement of roles or changes to the membership of the source group for rules. The calculation proceeds as a single job and typically completes within a few minutes.
  • Parallel Sharing Rule Recalculation is used to reduced the amount of time spent on the processing of sharing rule recalculations.
  • This feature can be turned on by contacting Salesforce support so that the sharing rules are processed asynchronously and split into multiple simultaneous execution threads based on load.
  • The processing is also more resilient; during a server restart, the jobs will be reinstated on the queue, and the process will continue when the server comes back online.
    sharing-rule-operation-in-progress

Granular Locking

  • Granular Locking is used to process changes to roles and groups in multiple threads to increase throughput on updates and avoiding locking errors.
  • It can be utilized to employ additional logic to allow multiple updates to proceed simultaneously if there is no hierarchical or other relationship between the roles or groups involved in the updates.
  • Without this feature, the code locks the entire table which makes two simultaneous operations conflict. With this feature, the code first analyze each operation and locks only the portions of the table touched by each, this makes it less likely that two operations will conflict each other, as a result, customer will experience lesser locks.
  • This feature can be enabled by contacting Salesforce support. (enabled by default actually)
  • Customers should consider using this feature only if they experience frequent and persistent locking that severely restricts their ability to manage both manual and automated updates at the same time, or severely degrades the throughput of integrations or other automated group maintenance operations.
  • Advantages of Granular Locking:
    • Groups in separate hierarchies can be modified concurrently
    • Public groups and roles that do not include territories are no longer blocked by territory operations
    • Users can be added to territories and public groups concurrently
    • User provisioning can now occur in parallel:
      • Portal user creation requires locks only if new portal roles are being created
      • Provisioning new portal users in existing accounts occurs concurrently.
    • Single-long running process, such as a role delete, blocks only a small subset of operations.

Deferred Sharing Maintenance

  • Deferred Sharing Maintenance is used to defer(turn off) the processing of group maintenance operations and sharing rule processing.
  • It is used to temporarily disable the processing of group maintenance operations , then make all the desired changes to role and group membership at the same time, then the processing can be resumed once the changes have completed.
  • It is useful when the company struggles to complete updates in timely fashion and also in an environment in which multiple systems are continually processing updates.
  • Deferred Sharing Maintenance steps:
    1. Administrator identifies a number of changes to the role hierarchy and group memberships, or updates to sharing rules.
    2. Administrator negotiates a maintenance window for completing the updates to sharing rules.
    3. Administrator prepares all the information required to perform all updates ahead of the planned maintenance window.
    4. Administrator uses deferral feature to essentially "turn off" processing of group maintenance operations, then makes all the desired changes to role and group membership at the same time.
    5. Administrator resumes processing group maintenance once the changes have completed, and the system performs a recalculation to make all the role and group changes take effect.
    6. At this point, the system is in a state that requires a full recalculation of all sharing rules, the administrator can resume sharing rule processing immediately or wait to start the process at a later time. After the sharing rule recalculation has completed, all the access changes take effect.
  • Best pratices for Deferred Sharing Maintenance:
    • benchmark how long the overall recalculation in Sandbox environment to see how long it is to take in production environment
    • smooth out any kinks in orchestrating deferred sharing maintenance
  • NOTE: Deferred Sharing Maintenance does not defer the recalculation of implicit sharing. The cascading effects to implicit shares continue to be processed immediately when sharing rules are changed by administrators or through the code.

Restructuring Accounts

  • No account should have more than 10,000 opportunities or cases related to it.
  • No more than 10,000 records of custom object should be related to a single account record.
  • No user should own more than 10,000 account records in Salesforce.
  • If not, there will be a higher chance of record-locking.

Performance Impact of Sharing Recalculation

Data Skew

  • When a single user owns more than 10,000 records of an object, there can be performance issues during sharing recalculation.
  • Solutions to Ownership Data Skew:
    • ownership of the records should be distributed across a greater number of users
    • do not assign a role to the user
    • if a role is needed, make sure it is at the top of role hierarchy
    • keep them out of public groups that could be used as the source for sharing rules
  • When an Account associates more than 10,000 child records, it can lead to poor performance of large data loads and updates.
  • Solutions to Parent/Child Data Skew:
    • distribute the child records across this collection of "parking" Accounts

Group Membership Locking

  • Lock errors can occur when updating role hierarchy or group membership through integration or the administration console.
  • Customers might occasionally receive a "could not acquire lock" error and have to repeat the operation.
  • Usually happens when executing large-scale data loads or integrations with other internal systems that are making changes to role and group structure, user assignments to roles and groups, or both.
  • When an administrator tries to change a user's role, or the customer tries to provision a new portal user, these simultaneous operations might be unable to secure the lock it requires.
  • This error occurs because the sharing system locks the tables holding group membership information during updates to prevent incompatible simultaneous updates or timing issues, both of which could lead to inaccurate data about users’ access rights.
  • The previous operation has already locked the table that maintains group membership and this will happen more frequently when there is lots of data and very large number of roles and public groups. Some manual operations such as creating user cannot be performed, multi-threading in integration with other systems might fail as they encounter so many lock errors that their throughput is greatly reduced.
  • Solutions to Group Membership Locking:
    • schedule separate group maintenance processes carefully so they don't overlap
    • implement retry logic in integrations and other automated group maintenance processes to recover from a failure to acquire a lock

Record-Level Locking

  • Lightning Platform employs record-level database locking to preserve the integrity of data during these updates.
  • Record-level Locking errors can occur when there are updates to parent records and children or updates to child records with same parent records in separate threads.
  • When parent and child records are updated simultaneously, Salesforce locks the parent and the child records to prevent inconsistencies.
  • When objects being processed have a parent-child relationship, the following two situations in particular pose a risk of producing locking errors:
    1. Updates to parent records (parent account records) and their children (opportunities) are being processed simultaneously in separate threads
    2. Updates to child records (related opportunities) that have the same parent records (accounts) are being processed simultaneously in separate threads.
  • Solutions to Record-Level Locking:
    • adding retry logic to integration code to solve occasional locking errors
    • sequence batches for mass updates and integrations so that same records are not updated in multiple threads simultaneously
    • use Public Read Only or Public Read/Write organization-wide default sharing model for all non-confidential data
    • use Controlled by Parent when configuring child objects to avoid creating implicit shares when possible
    • sequence operations on parent and child objects by ParentID and ensure that different threads are operating on unique sets of records
    • tune your updates for maximum throughput by working with batch sizes, timeout values, the Bulk API and other performance-optimizing techniques.

That's all about it! See you in next post!

Post was published on , last updated on .

Like the content? Support the author by paypal.me!