How to continuously monitor, balance, challenge, and reduce Technical Debt in a Salesforce org?

Vincent Finet
5 min readApr 21, 2022

--

For now, the branch is rather stable…

Technical Debt is usually defined by its negative impacts on your systems and/or applications:

  • performance is decreasing!
  • resolution time for bugs is increasing!
  • outdated documentation! Let’s check the code!!
  • adding new features is getting more and more complex

It’s time to check, in your Salesforce organization, the following things:

  • what is not documented enough inside the organization itself?
  • what is not used anymore?
  • what could be optimized?
  • what needs to be changed?
  • what could be removed for good?

That process will need to be put in place with a reasonable frequency. Depending on your need and your budget, this could be done every six months or every week. It also depends if this task is manual or automated for sure.

How would you approach this task?

First, you need to establish a list of items that you want to scan or monitor in your org. Try to answer that global question: What are the pain points? Is it the performance? Is it the cost of maintenance? Is it the quality of your data?

Second, for each item, you need to have a clear view of what is wrong, why this is wrong, and what needs to be done to correct it.

For example:

  • What is wrong? My custom fields on the Case object have no “Description”.
  • Why this is wrong? In the description, you could have the definition of that field, the default value, the flows that populate them, and the user stories that are related to this field. Right there in Salesforce.
  • What needs to be done? Don’t put “N/A” in the description, please! Check with all the project’s stack holders how to build a template of a basic description for a field. How do you reference the user stories in the description (like “#US-0001”)?

Additionally, you could have a KPI (or two) next to each item to better estimate your progress over the various iterations of the process. For example, last year, I had 160 fields with no description, last month it was 20 fields.

Now the next question is: How do I do that?

What tool can you use to check your technical debt in your Salesforce org?

Different tools exist to understand what happens in your org. Over the years, some awesome admins, developers, and companies came up with a lot of great ideas. But what if you don’t even know where to start?

Well, you should start with the Salesforce Optimizer. This tool is part of the Salesforce standard setup menu. For a long period, this tool was just generating a PDF file that would include metrics and best practices to follow. It has recently been revised as a Salesforce application, including the feature to store the metrics within Salesforce to see how well you are doing along the way.

Based on the findings of the Optimizer, you should have more clues on what to correct in your org. It might be things such as:

  • too many System Administrators,
  • custom Fields that are not included in Page Layouts,
  • custom Profiles or Permission Sets that are not assigned,
  • Role Hierarchy with too many levels or unused Roles,
  • Apex Classes with old API versions, or poor-code patterns,
  • empty Public Groups that are used only in Sharing Rules (you know… just in case!)

Additionally, you find tools on the AppExchange (or not) that will focus on a specific area. For example, if you need to scan your Apex code, you may use Apex PMD, CodeScan, or CheckMarks. If you need to optimize your Profiles and Permission Sets assignments, you may be interested in The Permissioner, or The Perm-Comparator. And more generally speaking, you definitely need to check Elements.cloud.

And then, you have OrgCheck.

Why did I create “OrgCheck”?

When you audit your org, you do it once. With a lot of data manipulations. After one or two months, I bet you will forget how you did it. And so, it is not efficient nor iterative.

According to my experience, it is good to document all the SOQL queries that you do (using the REST API, the Tooling API, the Dependency API, etc.) and explain the manipulation you do. That is a start. The knowledge is not lost. Good.

But what if you had all these queries and logic in an application? And what if this application did not require a Ph.D. to be installed? This is when I decided to create a Salesforce application (easy to install and easy to use) that would have all those queries and logic to iterate that process over and over again.

Introducing “OrgCheck”, an easy-to-install and easy-to-use Salesforce application to quickly analyze your org and its technical debt.

OrgCheck is currently available as a Salesforce application via an unlocked package for Dev Orgs, Production Orgs, and Sandboxes. Visit the website to install it in your org: OrgCheck Install TODAY!

It does not include any Apex code, everything is done in Javascript on your browser and no information is sent to another platform.

If you need to present the tool to your boss or your customer, please use the OrgCheck’s Public Presentation (Google Slide).

In its roadmap, OrgCheck has multiple new features and use cases, but the most important to me are:

  1. To be accessible from the AppExchange as a Salesforce Lab app.
  2. To move the queries and logic into a core library that could be included in the current Salesforce application and a new sfdx plugin. The plugin could then be used by a Continuous Integration to check frequently the health of your org.

Let’s start with real use cases!

Based on my experience with OrgCheck, I will continue our discussion by writing a series of articles that will guide you through typical Salesforce technical debt use cases.

Stay tuned!

Resources

--

--

Vincent Finet

I am a Technical Architect at Salesforce where I keep on learning new things. Sharing knowledge and experience is essential to me. Also OrgCheck’s author.