Bulk User data processing in Salesforce CRM -- How to Expedite?? Tips n Tricks \\ Part 4

 Objective: 

Welcome to Part4 of Expediting Bulk Data Processing Blog series. Here we would be looking at ways to improve the performance of processing User data in Bulk; 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 user updates.

• Snail paced performance while processing User create/updates.
• Repeated GML errors and Row Lock errors.

As a Salesforce Org evolves with Role Hierarchy, it is essential to have the Role Hierarchy of an Org to be properly maintained in Salesforce. As the Role Hierarchy gets complicated, the result will be GML OR ROW lock errors while processing User records.

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

Usecase:

Universal Container has roughly 25k Salesforce users and a 14 level deep Role Hierarchy. Universal Containers manages Salesforce users in a (legacy) "User Management System (UMS)". UMS is the system where User's territory/role assignment is defined and is integrated with Salesforce through an ETL tool for pushing user updates/creates from UMS to Salesforce. 

Universal Containers undergoes Sales Org expansion to have 5K new Sales Users to onboard in UMS and 10K existing users attribute changes (including profile) in UMS. Mark (Salesforce Administrator) is tasked with integrating these changes from UMS to Salesforce but he is observing very slow performance.

Performance has been hardly 500/hr and mostly erroring out due to GML, Row Lock errors. Considering 15K users to be integrated; 500/hr will take 30 plus hours to finish the task

Mark was aware of the “Defer Sharing Calculations” feature of Salesforce and above performance was observed despite enabling Defer sharing. Mark never expected this performance and approached Sneha for guidance.

Sneha analyzed the data || Explained Mark 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. Sneha checked on the Org and found that there are hardly any custom sharing Rules created for Account Object.
2. Sneha checked on users details planned for integration and found that their "to-be" Roles are at different branches of the Role Hierarchy.
3. The ETL tool was performing an UPSERT operation for users.

Defer Sharing only helps to suppress Custom sharing rules in the Org and it doesn't defer Salesforce (out of box driven) implicit sharing calculations resulting from the Role Hierarchy.

When a user gets assigned to a Role in the Role Hierarchy OR when a user's role changes; Salesforce initiates a implicit (Hierarchy) based sharing calculations to ensure that User' who stay above the (to-be) assigned Role in the Role Hierarchy continues to have visibility to the data from a hierarchy standpoint. This can also be referred as "top to bottom" based data visibility in Salesforce. Implicit sharing also ensures data integrity from a hierarchy aspect. And considering that the Org had a 14 level deep hierarchy, Role changes at user level was consuming sometime.

Added to that, ETL tool was performing an UPSERT operation which is not best advised while migrating large volume of users to salesforce. This is because UPSERT forces salesforce to perform a data comparison between the new data supplied from source system against existing data in salesforce. And then decide on if the data needs to be inserted or updated. BUT, as the data volume in salesforce increases .. so does the time taken by salesforce to perform data comparison check.

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

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

Solution:

Considering the fact that we have 15K users to be migrated and ETL tool performing UPSERT operation, Sneha advised below approach:

1. Split the UPSERT to 3 Operations. One is Insert, Second is  Update Operation for Users who need a Role change and Third is another Update operation for non-Role related Updates. 
2. Have the ETL to perform INSERT first; then UPDATE on Role changes, followed by UPDATE on non-role changes.
3. Sort the above operations based on User's Role.
4. Considering the deep level hierarchy; have a minimum batch size (between 1 to 10) set in ETL tool while performing INSERT and Role based update operation on User. AND, a higher batch size of 200 for non-Role based UPDATE operation.
5. If possible, run the non-Role based UPDATE operation on User Object in a multi-threaded manner to get faster throughput.

With the above approach, Mark observed 

• Huge reduction in Row lock and GML errors.
• Salesforce processing non-Role based user updates (including Profile changes) much faster than expected.

As a result, what was initially estimated as a 30 hr operation ended up consuming only 5 hrs, with an average throughput of 3k/hr.

Conclusion:

Mark was ecstatic with such a marked improvement and elated that he was able to meet/exceed the business expectations. He thanked Sneha for her suggestions.

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

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

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)