Introduction
XYZ Corp is a large technology company with a very highly customized Salesforce implementation. At the time of engagement, XYZ was just recovering from a chaotic and costly end-of-year realignment of their Sales hierarchy and account assignments. Not only did the realignment take far longer than originally planned, but Sales estimated that far from kicking the year off with a bang, the company actually lost revenue opportunities in the first month from the delays. The Salesforce Technical Enablement team was engaged to help ensure a smoother realignment for the coming year-end, providing best practice advice on both technical and process issues.
Problem Statement
Throughout the realignment, XYZ was plagued with two key issues: overall predictability of realignment tasks, and poor performance for key technical operations such as user role changes and account ownership changes. Accordingly, top priorities were investigating the performance issues and suggesting best practices around the org’s sharing configuration.
Engagement Approach
XYZ’s IT team mounted a broad project to fundamentally redesign the realignment process, and TE was called in early as advisors with three core tasks:
- Review XYZ’s sharing configuration and recommend best practices changes to improve overall performance.
- Work with Salesforce internal product teams on a detailed analysis of XYZ’s performance for user role and account ownership changes. Identify opportunities for optimizing the processing of these specific operations.
- Provide guidance to XYZ in modeling the realignment process in Sandbox to help them anticipate behavior in Production.
Key Observations and Recommendations
The XYZ team’s review of their sharing configuration and assignment processing uncovered a number of opportunities to apply best practices to improve performance:
- Child Record Access Settings – each Role in the Salesforce Role Hierarchy has a setting that controls what kind of access users in the role have to Opportunities, Cases and Contacts when they can see the parent Account. When users or accounts are moved between roles with different child record access settings, the system may have significant work to do to adjust access for affected users. The team recommended that a single policy for child record access be applied to all roles to reduce this extra processing.
- Portal Roles – when the owner of a portal account is changed, the roles that provide access to the portal users must be moved in the hierarchy if the new owner sits in a different role from the old owner. Moving a bunch of empty roles is just wasted effort in this process. The team recommended removing these empty portal roles.
- Number of Child records per Account – Salesforce’s Sales and Service applications include logic that makes sure users who can see an account can see the child records of that account, and vice-versa. When the owner of an account changes, triggering changes in visibility for other users, these internal rules also need to be adjusted. The more child records are associated with an account, the longer it takes to calculate these changes. The team recommended finding a way to reduce the number of child records associated with each account if possible.
- Use of the Bulk API – Most large enterprises can meet a reasonable SLA leveraging Apex to manage large scale realignments. However, some enterprise organizations have especially complex realignment requirements or very tight maintenance windows to complete their realignments. In these cases Salesforce has been able to provide peak performance and scalability by leveraging the bulk API when managing object shares in the system. The team recommended executing the assignment logic as a process which leverages the Bulk API due to the complexity of assignment logic and size of the organization.
Results
Based on these recommendations, XYZ made the following changes to their configuration, resulting in substantial performance improvements in early testing of realignment operations. In this phase of their work, the team focused on the user role change and account ownership change operations.
- Applied one single child record access setting to all roles in the hierarchy, which improved performance of user role changes by 95%
- Deleted their unused portal roles (more than half of all portal roles), which improved performance of account ownership changes by 36%
- Archived all but the last two years of closed opportunity records, greatly reducing the number of child records under each account and improving performance of account ownership changes up to 15%
- Executed the account territory alignment via the Bulk API improving performance of account ownership changes by 68%
Conclusion
XYZ Corp continues to look for additional improvements in their realignment process. And since performance is very sensitive to a customer’s exact configuration and data volumes, not everyone will have the same issues or see the same kinds of improvements. But by taking advantage of best practices for sharing configuration, all customers can benefit from substantial increases in performance and greater predictability in their realignment process.
—————————————————————————————————————–
Want to learn even more? See our papers on …
A Guide to Sharing Architecture – http://wiki.developerforce.com/page/A_Guide_to_Sharing_Architecture
Record-Level Access: Under the Hood – http://wiki.developerforce.com/page/Record-Level_Access:_Under_the_Hood
Designing Record Access for Enterprise Scale – http://wiki.developerforce.com/page/Designing_Record_Access_for_Enterprise_Scale
And even more architecture papers at http://wiki.developerforce.com/page/Architect_Core_Resources
—————————————————————————————————————–
About Technical Enablement Case Studies
The Salesforce Technical Enablement team engages with customers in “Prevention Mode”, providing education on complex implementation questions to stop problems before they happen. Our case studies are real world success stories showing how customers can solve major issues by applying best practices in their configuration and platform development.