Part II: Back End Review: Reviewing Technical Debt | Integrations | Data

Now that you have high-level information on your new company, it is time to dig under the hood of your Salesforce org.

What is under the hood you ask? Well, I can’t tell you – that will be up to you to discover! Fun right? During my time as an Administrator and Consultant, I have been asked by many ‘Can Salesforce do XYZ?’. The answer is always yes because Salesforce is flexible, but it is a best practice that we ask another question on whether we ‘should’ do that thing or not. Depending on how old your org is, there may not have been pre-built functionality yet, thus requiring custom development that you need to replace or change. There could be things that we historically built that are not used anymore. This is where the term technical debt comes into play. In this article, we will discuss how to review the technical debt, integrations, and bad data in your org.

Technical Debt

All orgs will organically have technical debt, but it is something you need to evaluate and prioritize over time. In software development, technical debt is the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. As with personal financial debt, the amount of technical debt will vary by org and should be paid back over time. Not paying it back has consequences. I would ask myself, what are the things in this org that are:

  • Not used anymore
    • Inactive items (flows, validation rules, process builder, workflows)
    • Hard-coded references that may break
  • Custom development
    • that could be replaced by standard functionality
    • that is difficult to maintain or breaks often
    • that no longer meets the needs of the users or use case
    • that is not scalable for your company

Some technical debt may be something you can reuse. When evaluating your instance keep that in mind as it may save you time down the road in future solutions.

Evaluate your Orgs Technical Debt

  • Salesforce provides the Optimizer which helps identify issues that require immediate attention along with recommendations for the next steps.
  • AppExchange offerings that can help you find and evaluate your org.
  • There will likely be some legacy knowledge around what was built and what isn’t working. We will cover this more in part 3 of the series when we cover prioritization and strategy.
  • Block your calendar to take time to review different metadata areas of the org as you onboard.

How to limit technical debt moving forward

  • Leverage pre-built functionality that Salesforce provides whenever possible. Sometimes you should consider altering processes to fit standard functionality as a better way to keep the org scalable.
  • Before making changes, ask the ‘should we’ question – just because we CAN do anything with Salesforce does not mean we SHOULD do everything. Thinking of the long game will set you up for success.
  • Leverage the AppExchange for pre-build solutions instead of building things yourself.
  • Stick to a strong DevOps process to ensure what you are building works, meets the needs, and is documented properly. If your company does not have a DevOps process, be the pioneer and create one!
  • Don’t work in a silo. Ensure to include many stakeholders to ensure that there are no gotcha that you as an individual are not thinking of.

Package Integrations

When onboarding into a new org, one of the first areas in Setup I tend to look is at what packages are installed, or what integrations are important to the company.

  • Setup>Installed Packages

This gives you quick insight into what packages may be installed in the org that you should be aware of as you work. If you see, this could be a topic of conversation when you speak to Sales leadership. If you see Survey Monkey, this could be a topic of conversation when you speak to Support leadership.

As you look through the integrations, there is helpful package attributes that will be important to you. For example, what is the status of the install (is it active or expired), when the package was installed, and by whom? This information can give you an idea of who might hold the background information if it is not documented well.

As you focus on cleaning up your org over time, there may be a use case for uninstalling a package. Please be aware, there are important considerations when uninstalling a package in your org. Here is a help article from Salesforce outlining what you should keep in mind.

Review the Data

Capturing quality data at the right time and enriching it throughout your records journey through Salesforce is critical for the data output to be actionable and insightful for your users and leadership.

Early on in your onboarding, it is critical for you to get a sense of the health of the data in your org. Below are some quick tips on ways I got a snapshot of the data in my orgs.

  • Get a good understanding of what reports and dashboards are being used by your users?
  • I leverage packages on the AppExchange such as Field Trip & which can help you get a quick understanding of what fields are used and which are not and the % of the time they are used. This is tricky with formula fields, but you can run your own reporting to understand those numbers easily.
  • Review the required fields on page layouts on each object. What is required for the creation of a record?
  • Review the validation rules within your org on each object. What is being required as the records are changed in your org?

This information will give you insight into the technical debt, installed packages, and quality of data. In the next series, we will take this a little further into collecting valuable information from your users and stakeholders to being to prioritize and strategize the changes to your org.

Up Next: Now that we have the high-level information on your new company, we will discuss how to complete the intake of information and how to prioritize and strategize what to work on so you can create an actionable plan. 

Part I

Where to Start Understanding the Business & Identifying Processes

Part II

Back End Review Reviewing Technical Debt, Integrations, & Data

Part III

Prioritize and Strategize So You Can Properly Complete Your Assessment

Part IV

Let’s Create an Actionable Plan and a System to Manage Ongoing Requests

Candy Goll

Candy Goll

Solution Architect

Unraveling challenges, overcoming obstacles, and exploring what's possible on the Salesforce platform.

Challenges on the platform are no hurdle for Candy, she clears hurdles on the Snowboard and on the Salesforce platform, like no other. Candy is your go-to Salesforce Solution Engineer. After inadvertently falling into the Salesforce ecosystem as an administrator, spending time at several consulting partners, and even working at Salesforce as a Solutions Engineer, she excels in solving large challenges. She is most commonly known for tackling complex situations and breaking them down into bite-sized pieces, to create a path to success. Candy is a Salesforce expert who thrives on partnering with companies to build scalable solutions by leveraging the Salesforce platform.

About Roycon
We’re an Austin-based Salesforce Consulting Partner, with a passion and belief that the Salesforce platform’s capabilities can help businesses run more efficiently and effectively. Whether you are just getting started with Salesforce or looking to realize its full potential, Roycon specializes in Salesforce Implementations, Salesforce Ongoing Support, and Salesforce Integrations, and Development. We’re the certified partner to guide the way to increase Salesforce Adoption, make strategic decisions, and build your Salesforce Roadmap for success.