AD2A -- Admin to Architect Series in Salesforce

  Objective:   Welcome to this chapter where we would be exploring another approach to expedite Data Masking in Salesforce. This is a continuation to the Data Masking Approach discussed in our previous article (https://manojn2sf.blogspot.com/2022/01/expedite-data-masking-in-salesforce.html). The approach we discussed in our previous article had A Common database/sandbox which will be sync'd with sandboxes masked data as and when we refresh it. The masked data in this common database/sandbox will then be re-used to apply data masking for a newly refreshed sandbox. In this article, the alternate approach would be providing a similar performance as referred in previous article but we will be re-arranging the data flow with regards to a use case as discussed below. As you read through, you will understand how this approach will serve multiple benefits. Usecase: Universal Builders has roughly  20k  Salesforce users and  150k  external Partner Users. Agile methodology is followed and as

  Objective:   Welcome to this chapter where we would be exploring approaches to expedite data masking in a Salesforce Full Copy sandbox that has millions of data.  Considering GDPR regulations, its imminent for the Salesforce Org to mask the Restricted and PII related data in an instance. But as the data in the instance grows, our Dev/Admin would eventually see the Data Masking Operation taking more time (Sometimes its days and sometimes its weeks).  This would also result in a delay with sandbox readiness and  further delay feature deliverables for an Org, if it has a development life cycle involving SIT/UAT/Performance test Sign OFF in a Full copy sandbox prior to deploying features to production. With that lets look at Universal Builders Instance where Eric wears the hat of salesforce administrator and Smita is our Solution Architect. Lets look at their usecase in detail. Usecase: Universal Builders has roughly  20k  Salesforce users and 150k  external Partner Users. Agile methodol

  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 use

  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 a

Welcome to Part 2 of the Expediting Bulk Data Processing Blog series. Here we would be looking at certain smart ways of improving performance of Batch Job in updating/processing large volume of data. Objective : As a Recap, Part 1 of this series looked at impact of   Data Skew - Ownership on holding the performance of Bulk data processing and how we could mitigate it accordingly (I would encourage you to visit Part1 of this series if you haven’t already) In this article, we will be looking at some techniques on improving the performance of existing Batch Job. I am sure some of our Salesforce Admins/Developers would have observed Batch Job slowness while processing large volume of data. Triggers OR backend customizations could be a factor to slowness BUT what if we need those customizations to execute as part of data updates and still expect Batch Job to perform faster? This is exactly the situation with Mike, who is a Salesforce Developer with System Administrator Profile i