Spring Cleaning your Salesforce Org

Introduction

Salesforce Orgs which have been productive for a few years can easily accumulate unwanted baggage over time. This baggage can take many forms, from customizations which prevent us from leveraging the latest platform functionality, to unneeded fields in forms which were added at one point and never removed even though they are no longer required, to hundreds of reports which are not being consumed by anyone. Cleaning your Salesforce org suddenly appears as something that seems like it will need to be done sooner or later.

It is useful to refer to all these accumulated inefficiencies as the Technical Debt which is present in our Orgs. Unfortunately, Technical Debt has the tendency to accumulate slowly, due to the urgency of making changes which have been not been thoroughly designed or analysed. Eventually, excessive Technical Debt can have very significant impact on an Org, from performance degradation to reducing the ROI of the whole platform by giving end users a poor and inefficient user experience. In a worst-case scenario the Org becomes so unwieldy to use that users revert back to managing their work via email and Excel, with only pro-forma usage of the Salesforce platform.

Once we’re convinced that we need to address or at least control the Technical Debt present in our instances, we have to answer the following questions:

How do I identify existing Technical Debt?
what strategy should I use to bring it under control?
How do I implement the strategy I’ve chosen?

Identifying Technical Debt:

In general, Technical Debt in Salesforce can be grouped in the following categories:

• Unneeded customizations – This is the main category when we think about Technical Debt in Salesforce. The advantages of staying as close to Out of Box as possible, and of customizing with clicks vs code, are sufficiently preached by Salesforce to have to be repeated here.
• Unused form fields and data columns and tables – A clear indication that our Org is overly customized is the presence of unused fields on the database. These typically map to fields on forms which users just ignore, never understood what they are on the form for, and just add to the visual clutter or the user interface. Applications such as Field Trip can help us detect unused fields. There are also a number of tools on the App Exchange which can help us analyze the data model of our Org and update (or create) a Data Dictionary.
• Poor quality code – Code which has been added to the org for necessary customizations, but does not follow Salesforce, APEX or JavaScript best practices contributes significantly to Technical Debt. There are a number of tools and applications which can review your code and highlight non-compliance issues.
• Reports – Reporting is an area where it is quite common to see reports which have outlived their usefulness remain on the Org simply because no one has bothered to remove them.
• Open Source Libraries – Open Source libraries, especially JavaScript frameworks, are often uploaded to Orgs to provide features which developers think they need (although in most cases the same features are likely available in the platform components). Even when there is a real need, this in itself may constitute Technical Debt if developers are free to use any framework of their choosing without complying withe organization’s policies about use of Open Source Software. And even if these policies are followed, it is quite common for older versions of these libraries to hang around long after they’ve been replaced by newer versions.

Strategies for Cleaning Salesforce Orgs

Once you have identified the main sources of your technical debt, you can either decide for a full re-implementation of your Salesforce org or for an ongoing and regular reduction of the technical debt. In the first case, you should pause the delivery all of the new releases and focus on the new implementation, leveraging the Salesforce out-of-the-box functionality.

If you can chose for a gradual reduction of the technical debt and keep delivering functionality, a good practice is always to reserve a percentage of each sprint for remediation work, where prioritization is key. Quite often, many companies choose cleaning Salesforce implementations over starting afresh, though both approaches have their drawbacks.

In both cases, regular automated inspections of the code and instances are a must. Start your Quality Clouds trial now and understand your technical debt sources.

Happy Spring Cleaning!