Spring Cleaning your Salesforce Org

Quality Clouds > Coding  > Spring Cleaning your Salesforce Org

Spring Cleaning your Salesforce Org

Audience: Salesforce consultants; architects; platform owners; administrators
Reading time: 12 minutes


Salesforce Orgs which have been productive for a few years can easily accumulate unwanted baggage over time. This baggage can take many forms, from customisations 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.

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 customisations – 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 customising 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 customised 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 analyse 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 customisations, 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 organisation’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.


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.

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!

No Comments

Post a Comment