Why do you clean your house, when you know it will get messy again? I guess the most usual reason is to maintain hygiene. Same applies to your Salesforce instance. The cleaner it is, better it will work for your business. Lesser is your business processes susceptible to catch any disease (failure).
[blockquote]Cleanup Cleanup.. Everybody let’s cleanup[/blockquote]
What is to be cleaned in Salesforce org?
This kid’s rhyme always reminds me of my struggles in working with Salesforce instances, which have evolved over several years. There have been huge platform improvements over the years, to ease out this pain. Still, a lot of responsibility lies with Instance owner(s). One thing, you are sure to find in old instances is, a lot of unwanted stuff. As commonly presumed, this unwanted stuff is often stated to be “Just a backup”. But, over time, it poses more problems than presumed benefits.
Why is Cleaning Required?
Let’s take some examples:-
- Disabled triggers - they are disabled, but still consuming your apex code limit. Not to mention, it’s dead code, which is not required.
- Disabled or unused workflows/ process builders - just creating more confusions and consuming Salesforce limits
- Unused items (code/ object/ fields/ buttons) - not just creating confusion, but also consuming precious Salesforce limits, which restricts future customizations
- Stale/ Old test classes – often forgotten, this can be a nightmare to get by. Over the years, as business rules change, the test classes also need to fix accordingly. This not just ensures that those test classes can validate business logic, but also ensure that you do not get any last minute surprises when your new shiny deployment fails due to stale test classes
- Silver-bullets (workarounds) – little workarounds added to save time and get work done, may work for some time, but can cause long term negative implications unless addressed appropriately
[blockquote]Garbage is not good for environment; and for your Salesforce environment[/blockquote]
Well, I’m sure we all have few or all of these mentioned issues in their respective Salesforce instances. Often in hindsight, these situations arise and are sometimes unavoidable. And let’s be real, often it is time consuming to handle these, which means additional cost, so it is deferred (sometimes forever).
But, as it grows over time, it becomes more and more costly to get rid of these. Just like an unwanted weed. It’s better to cure it at right time, before it gets out of hand.
Best Practices for Regular Instance Management
There are lots of steps that one can follow to take care of these effectively. Following are some recommended steps, which can be regularly performed for fine tuning and upkeep of your Salesforce environment.
Preferably a periodic process review to reassess your business processes and how they align with your Salesforce processes. This is often missed and most impactful exercise
Run Salesforce Optimizer
This Salesforce utility automatically identifies all probable anomalies and recommend appropriate best practices. Find more at Salesforce Optimizer. Upon execution, it generates a report and sends it via email. This tool assesses a comprehensive list of metadata components within your Salesforce instance and advises on how to configure utilize them in an optimal way.
Code Quality Scan
Salesforce and Checkmarx also provide a code quality assessment tool. It is freely available (with limits on number of times you can run it) and very effective in analyzing code quality of all Apex code (apex classes and triggers) within your Salesforce instance. In fact, it is so effective, that any managed package submitted to Salesforce is recommended to be run through this tool prior to Security review submission (Salesforce recommends it). Access it at Force.com Source Scanner Portal
Whenever anything is being rendered not for use or planned to be decommissioned, demarcate them in help or description or even within label (whatever applies) or all of these. This helps notify users, what they should not be using. A few approaches can be:
- Store business process details within description of relevant component (wherever description field is available)
- Update label to indicate that the item will be decommissioned
Maintain Decommission Tracker
Keep a list of all components (object, field, class, page, trigger, workflow, page layout) to be or already decommissioned. For items to be decommissioned in future, maintain a date when they are to be decommissioned.
Define Decommission schedule
Identify a plan to remove decommissioned items. Typically a quarterly process to remove all decommissioned items. If some items are to be retained for extended duration, update the decommission date in the Tracker
Measure and Monitor Technical Debt
This in itself can be a complete post of its own. In basic terms, technical debt is measure of all the workarounds, silver-bullets, tricks added to your functionality, which may be fulfilling your current needs, but is mostly certainly not an optimal practice. As you can understand, most of these workarounds are designed to solve a specific problem, but may not be optimal for handling processes at large for a prolonged usage. Unfortunately, most of these “silver-bullets” are added and forgotten, until something breaks due to them and then either a good solution is fixed, or it gets replaced with another “silver-bullet”. Maintain a tracker of all these “silver-bullets” and ensure that they are prioritized regularly. So that, they don’t become a nightmare at later stage.
Well, there can definitely be more activities added to the list. But, above list gives an adequate list of activities to keep Salesforce instance lean, clean and shining.