Bulk Partner Account Owner Changes in Salesforce CRM -- How to Expedite?? Tips n Tricks \\ Part3

 Objective: 

Welcome to Part3 of Expediting Bulk Data Processing Blog series. Here we would be looking at ways to improve the performance of Account ownership transfer pertaining to Partner Accounts; especially for Large Salesforce Orgs with complex Role Hierarchy.

I am sure some of our Salesforce Admins/Dev managing the Large Salesforce Orgs would have faced below experience while processing large volume of account ownership changes.

• Snail paced performance of Partner Account Ownership changes.
• Repeated GML errors and Row Lock errors.

As a Salesforce Org evolves with more user adoption, custom functionalities and housing huge data; another aspect of Salesforce that has potential to grow will be -> Role Hierarchy. Role Hierarchy of an Org has to be properly maintained in Salesforce. The Larger and complicated the Role Hierarchy becomes, the result will be GML OR ROW lock errors while,

-> Creating Roles/Users.

-> User's Role Update.

-> Record Ownership Update.

And above situation extrapolates, if the Org has Partner Account Management enabled with large number of Partner Accounts. This is because Salesforce Out of box behavior will create (1 to 3) Partner Roles for every Partner Account.

With that lets look at Universal Containers Instance where Sakshi wears the hat of salesforce administrator and Dave is our Solution Architect. Lets look at their usecase in detail.

Usecase:

Universal Container has roughly 100k Partner users, 40k Partner Accounts and a 16 level deep Role Hierarchy. Universal Containers undergoes a Sales Org re-structuring and Sakshi (Salesforce Administrator) is tasked with updating Account Ownership for 30K Partner Accounts, so that Account Ownership aligns with the latest Org Structure of Universal Container.

Sakshi was aware of the “Defer Sharing Calculations” feature of Salesforce. Sakshi enabled that in a Full Copy sandbox and tested on account ownership updates for 5K Accounts. To her surprise, the performance was hardly 1k/hr and threw few GML errors also. Sakshi re-processed the error records and the overall testing took roughly 6 hours to process 5K Partner Accounts. Implies for 30K Partner Accounts, it will take 30 plus hours to complete. Sakshi never expected this performance and approached Dave for guidance.

Dave analysed the data || Explained Sakshi on the reason behind slowness despite Defer Sharing enabled and provided a suggestion that proved to be a game changer. Lets have a look at them.

Analysis:

1. Dave checked on the Org and found that there are hardly any custom sharing Rules created for Account Object.
2. Dave checked on Current Account Owners as well as new account owners for the 30k Partner Accounts. Overall Count of Current and New Owners (combined) is 2k.
3. Dave checked on Roles of the Current Account Owner and New Account Owner for some Partner Accounts. With that Dave, explained to Sakshi on the reason behind slowness.

The main reason why Account ownership changes slowed was due to the 16 level hierarchy and how SFDC behaves while updating Account owner. Lets consider a sample Role Hierarchy as below.

The Hierarchy details are as below:

1. User Sam is assigned to Role “Commercial Channel” and Sam owns Partner Account “XYZ”.
2. When an Account is enabled as Partner Account, Salesforce creates 3 partner Roles in a hierarchical manner. The 3 Partner Roles are : “Partner User” which reports to “Partner Manager” and “Partner Manager” reports to “Partner Executive”. The “Partner Executive” will then appear as a subordinate to Account Owner’s Role in the Hierarchy.  This is an out of box design of Salesforce and hence we see 3 Roles getting created for Partner Account “XYZ” and they eventually report to “Commercial Channel” (which is the Role of the Account owner Sam). One can control the number of Partner Roles creation from 3 to 2 or 1 by navigating to set up || Partners || Settings || Set up Portal Roles and User Defaults || Define the Number of Portal Roles in this page.
3. The New Account owner “Amit” resides in different branch of the hierarchy and is assigned to Role “Commercial Solns”.
4. For an Org with Partner Account Management enabled, we would have Roles meant for internal Users as well as “Salesforce created” Partner Roles meant for external Partners.
5. For every Account owner part of Role Hierarchy, Salesforce introduces “Implicit Sharing” mode of data visibility due to the Role Hierarchy. Such an Implicit Sharing ensures a Top – bottom style of data visibility. Implies, a User assigned at the Top role (Global Solns) will see the data that is visible to the users assigned to (hierarchy of) subordinates ( Commerical Solns and Enterprise Solns)

Now, when there is a change of Account Owner from Sam to Amit for Partner Account “XYZ”, Salesforce update execution is as below,

1. Re-assigning the 3 Partner Roles from Commercial Channel to Commerical Solns
2. Navigating through the hierarchy and re-evaluate Role Hierarchy Driven Implicit Sharing visibility for the records impacted by this ownership change. Implies,

• Salesforce has to ensure that Users that are assigned to Commercial Solns and Roles above in the Hierarchy has visibility to the Data Owned OR Seen by the Partners.
• Salesforce has to ensure that Users assigned to Commercial Channel and Roles above in the Hierarchy (Except World Wide Org) no longer have visibility to data owned OR seen by the Partner.

As a result, in our Org with 16 levels of Role Hierarchy and considering the additional Partner Roles tagged with Partner accounts;

-> Salesforce has to perform the Implicit Sharing Calculations and Partner Role re-alignment for every Partner Account owner change.

-> As the Org grows from number of Partner accounts and Role Hierarchy standpoint; above operation of Salesforce is very time consuming. Hence, the slowness in Partner Account Ownership Update performance.

With that, lets see what trick does Dave have to overcome this challenge.

Aren’t you curious? Let’s Cut to the Chase  😊

Solution:

Considering the fact that we have 2K users (Combined number of Existing and New Account owners) associated with 30K Partner Accounts and how Salesforce out of box design behaves for account Ownership change, Dave’s suggestion to Sakshi for expediting account ownership performance is as below:

Step 1: Temporary Role Creation:

•  Create a Temporary Role that resides outside the Role Hierarchy. Lets call it “Acc-temp”. 
• This Role can be sibling to the top most role in the hierarchy OR “report-to” top most Role in the hierarchy. In our case, Sakshi would be creating “Acc-Temp” Role reporting to “World Wide Org” (Top Role).

Step 2: User – Role Backup

• Take a backup of 2K users along with their current Role. The extract of the back up should include columns like Userid, UserRoleid, Username and any other External id fields in the org.

Step 3: Enable Defer Sharing

• Turn ON Defer Sharing calculation, which enables salesforce to skip Custom Sharing Rule calculations and Group membership calculations of the Org.

Step 4: User Role Update

• Create “Role update.csv” file for the 2k users containing 2 columns. Userid and UserRole id.
• Here User Role id value for the users will the id of the role “Acc-Temp”.
• Using DataLoader Or workbench OR a similar tool, perform a Update operation on the User Object with Batchsize of 1.
• This step is very critical because, we are assigning all the Current and “New” account Owners (2K) to the temporary Role. As a result, the hierarchy becomes flat and when account owner update gets processed salesforce doesn’t have to navigate through the Role Hierarchy. The associated Hierarchy-driven implicit sharing calculations can thus be bypassed.

Step 5: Account Owner Update

• After processing Role update for users, Account Owner update for the 30K Partner accounts can be processed. 
• Batch size of this operation can be 10. This is because of the additional Partner Roles that SFDC has to process, along with the account owner Update.
• Because of Previous step, Account owner update throughput improved to 5k/hr (on average) and this is 4x times better compared to 1K/hr throughput observed earlier.

 Step 6: Revert User Role Update

• Re-use the back up file taken in step 2 and prepare an “User Update” csv with 2 columns. Userid and UserRole id (The value in the backupfile).
• Then Perform the Update process via Dataloader or workbench; with batch size of 1.
• This is essential to restore Users back to their actual role and re-instate their Data Visibility.

And finally, resume Sharing Calculations.

** Below image depicts the Role Hierarchy that includes the “Acc-Temp” role.

Sakshi (Like us) felt, there are few additional steps to be performed compared to the single Owner Update operation. But, when she went through the steps she saw remarkable improvement in performance and this approach saved a lot of time (compared to estimated 30 hrs duration for the direct account owner update process). Details as below:

Task	Effort (in hrs)
Step 1: Temporary Role Creation	0.25
Step 2: User Role Back up	0.5
Step 3: User Role Update	3
Step 4: Account Owner Update	6
Step 5: Revert User Role Update	3
Total Hrs	12.75
	57% improvement OR Time saved compared to est 30hrs.

Conclusion:

Sakshi was ecstatic with such a marked improvement and elated that she was able to meet/exceed the business expectations. She thanked Dave for his suggestions.

Lets give both of them a big Cheer of their accomplishment. 👋👋

The approach suggested in this article has been a great time saver based on my experience. It takes advantage of Salesforce Flat Role Hierarchy Concept and (conceptually) less number of users owning N number of accounts.

And so, we conclude Part 3 of this Blog series. I hope this article helps you to resolve similar issues at your end. Am eager to hear your feedback and inputs.

Our Next article will focus on improving performance while Processing Users.

Article Links/References

1. Salesforce Built-In Sharing behavior  (https://help.salesforce.com/articleView?id=sharing_across_objects.htm&type=5)
2. Salesforce Sharing Architecture  ( https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/sharing_architecture.pdf) 
3. Related Series -- Part2 (https://manojn2sf.blogspot.com/2021/01/bulk-data-processing-in-salesforce-crm.html)