Blog

One of the biggest challenges I have faced during my experience as a Solution architect is having to take over a mature Salesforce instance. Which areas should I look into? Which tools can I use for the analysis? How can I fix what’s broken? How can I continually monitor and maintain a cleaned up instance? These are some of the questions which baffled me every time I began working with a mature Salesforce org. The reason why I lay so much emphasis on tidying up a mature org is that I deem it risky business to start working on a new implementation or project when the current state of an instance is in a disarray. In my opinion, chaotic metadata/data structure is the worst adversary of a software development project (declarative or programmatic) and it ought to be ironed out before the implementation begins. Moreover, providing a satisfying user experience should always be one of the primary goals of a software project and efforts should also be channelized towards improving it to the best possible extent. I have compiled a list of five crucial areas that should be analyzed when you are trying to make your Salesforce instance a better world to work in:

1. Data
   Maintaining data quality in an org is a continuous effort and should be taken seriously. There are multiple tools like CRMfusion DemandTools, Cloudingo & RingLead Data Cleanse that can help you identify and eliminate unwanted duplicates. Appexchange is a great place to go start exploring and finding the data de-duplication tool that best serves your data cleansing needs. Setting up duplicate management rules either via native or third part apps, enforcing data entry standards and constantly monitoring data quality is arguably one of the most critical tasks for making your users more productive and ensuring better reporting/data analysis. Taking a look at Data Storage and File Storage is a great way to  find out which objects and users are contributing the most to data and file storage in an org. Using  a robust third party app, you can easily analyze data, find duplicates, merge them and block them from feeding into the org via different sources.  Here’s a snapshot of what a quick analysis with Cloudingo looks like:

   

2. Security and Sharing
   Analyzing the ‘Who Sees What‘ in a mature org is another area of substance. What does the OWD (Organization Wide Defaults) for various objects look like? How are the Sharing Rules configured? How well thought-out is the Role Hierarchy? How well are the Profiles set up? How many System Administrators does the org have? Are all of these System Admins worthy of having the View All Data and Modify All Data superpowers? These are the few questions that everyone should ask and care about when fixing the security and sharing configuration in an org. Believe it or not, I worked with a client that had 49 system administrators, a majority of who didn’t know how to administer the system. Result? The org had almost 600-700 custom fields across most of the standard objects, haphazard business rules scattered all over the place, a ton of page layouts and records types and a missing governance framework with sub-par change management. I immediately cut down the number of system administrators to 5, narrowed down access via OWD, created sharing rules to open up access as needed, re-evaluated and re-configured the role hierarchy and enforced best practices around change management.
3. Business Rules
   Workflow Rules, Process Builder processes, Flows, Validation Rules and any other business logic in the org that can cause automatic actions to trigger or prevent users from saving records ought to be chewed over. Are these business rules being created directly in Production? Is there a centralized process to control who is creating them and why? Do these rules have elaborate description to explain what they are supposed to accomplish? Can multiple workflow rules be consolidated into a single Process? Are there any business rules that don’t make sense and can be permanently erased? You must ask these questions when performing a health check on a mature org. While working with another client, the system administrator complained that he was getting frequent emails from Salesforce about hitting the limits for maximum transactions/hour limit everyday. With a little bit of investigation, seven time dependent workflow rules were found to be the culprit. And I was fortunately able to delete all of them. How? Two of them didn’t make sense and  the other five were no longer required. I also transformed a major chunk of validation rules and workflow rules to utilizing Custom Settings thus making them more maintainable in the long run.
4. Field usage, Page layouts, Record Types
   This analysis step is primarily targeted towards improving user experience. Are there way too many fields on a page layout? Are they getting populated on a frequent basis? Do you see 10+ record types or page layouts on a single object? It’s important to whip it all into shape to ensure better data quality and an enhanced user experience. With too many and overlapping page layouts, it becomes harder to keep a track of which field is on which page layout. Moreover, when creating a new custom field, you have more-than-needed page layouts to consider which can be time consuming.  For field usage analysis, I highly recommend an app like Field Trip that can help you create reports and illustrative dashboards to find under-utilized fields. Following is a preview of how the analysis with Field Trip can be brought into reports and dashboards for a better visualization:

   

   In case you want to do something similar, Johan Yu has explained the above setup quite well in a related blog post.

5. Code – Apex triggers, Apex classes etc.
   Analyzing the existing code in an org is of paramount importance. If you are from a developer background or have developer assistance, this shouldn’t be extremely challenging. Is the code bulkified? How much test coverage does the org currently have? Is the code even needed in the first place? Can the code be converted into a workflow rule or process or flow? Is the code following best practices? If the answers to any of the above question/(s) comes across as being an issue, it’s time to heap together all the problematic code and get it fixed. Too much code and no accountability for what it all does can have grave repercussions. It’s vital to have documentation for every code piece that you have, either in form of a wiki or a comment header inside the code piece itself.

There is obviously a plethora of other areas (like custom objects/tabs usage, sales cycle setup, user and  feature license usage, installed apps) that you should investigate but what I listed above should give you a decent head-start. Now the million dollar question is that where and how exactly do you start digging in to analyze the above. Apart from the tools that I mentioned before, the following should provide you with a neat summary of metadata/data/license usage in your org:

• System Overview
• Company Information
• Octopus (third party app)

System Overview and Company Information pages in Salesforce are an incredible way to get a bird’s-eye view of an org’s structure/configuration/setup. Here are a few other miscellaneous tips that can help you establish best practices and design standards for better governance in an org in the long run:

• All metadata (even fields) should have a Description or Help text, wherever applicable.
• Minimize the number of Profiles in an org otherwise field and record security can become harder to manage. More profiles can also lead to more page layouts thus adding to the pain.
• Creating automated processes in Production should be a strict no-no. This applies to any kind of metadata but building workflow rules, processes , flows etc. directly in Production can wreak havoc and should religiously be done in Sandbox first.
• Teach users and admins to write better formulas to avoid limits on compile size and character size. Since formulas are an integral part of the Salesforce CRM with widespread usage across formula fields, validation rules, workflow rules, process builder etc, it’s important to optimize when building them.
• Automate anything that you possibly can and when you do, build it to be scalable and maintainable.
• Focus on Documentation! I cannot stress enough how important this is.
• Make your super users and admins go through a mandatory training on Trailhead, an interactive learning path designed by Salesforce. Create a Trailhead chatter group, encourage members to take challenges and earn badges.
• Thoroughly test a metadata change, no matter how small or insignificant it seems to be.
• Design first and then configure. Do not jump into the implementation without giving it enough thought.

I also suggest going through the 25 Configuration Commandments help article focused on Salesforce best practices. I try my level best to follow most of them during my day-to-day Salesforce activities and hope that you incorporate them as well. Your goal should always be to make life easier not only for the current users but also for the ones who will be using or administering the system in the future.

Good luck with cleaning up that org!