How to Manage Tech Debt Salesforce

How to Manage Technical Debt in Salesforce

Managing technical debt is a challenge almost all enterprises face. As Salesforce orgs age and the companies they service grow in complexity, technical debt accumulates. While a small amount of technical debt is normal, a Salesforce org that contains too much technical debt is brittle, can have performance issues, and is increasingly more expensive to maintain over time. 

In this post, we examine how long term cost of ownership and technical debt are connected and leave you with actionable insight on:

  • Why long term cost of ownership (LTCO) is something every enterprise should be thinking about.
  • Why long term cost of ownership is often not considered when validating Salesforce solutions.
  • Five best practices enterprises can follow to develop scalable Salesforce solutions that reduce technical debt.

What is Technical Debt?

Technical debt is “the ongoing cost of expedient decisions made when implementing code” click here to read more

In Salesforce terms, technical debt extends beyond code and includes abandoned or overlapping processes, workflows, custom fields, etc.. Technical Debt is classified as either incurred or evolved. Incurred technical debt is deliberately or inadvertently accumulated; like using an obsolete method of solving a problem. For example, using a Salesforce feature that is on the roadmap to be retired.

Evolved technical debt is created over time as the result of changes both in Salesforce’s platform and your organization’s Salesforce org. For example, when an organization has to retire a solution because the number of Salesforce contacts has grown significantly; making the historic solution obsolete. 

How Technical Debt Impacts the Long Term Cost of Ownership

A common pitfall that enterprises face is only considering the short term costs associated with Salesforce customization. It is easier to think tangibly about short term consulting, internal time, and subscription costs. However, it is more difficult to consider and balance that against the long term costs associated with maintaining a solution, aggregating more data or putting off those Salesforce clean up projects.  

What is “Long Term Cost of Ownership”? 

Relative to Salesforce, Long Term Cost of Ownership (LTCO) is the work that is involved to maintain a Salesforce instance post-deployment. This includes subscription and license costs, managing bug fixes, user errors, supporting current users, and net new projects. 

The impact(s) of long term maintenance costs are especially important for enterprises because the issue is magnified at scale. More employees equals more customization and often more issues. The more Salesforce is customized, the more likely there are multiple solutions addressing the same problem (which creates technical debt as processes are abandoned due to lack of adoption). 

Enterprises also produce a massive amount of data. Meaning,  whatever is built in Salesforce, has to withstand the pressure of that data.

“Can your custom solution bear the weight of one million records over time?”

This does not mean that organizations should not customize their orgs. It means that all Salesforce customization should be developed strategically to address the overall needs of the company, not just the siloed needs of individual departments (this is discussed further below). 

Why Many Enterprises Do Not Consider LTCO

Often organizations are looking for a consultancy or their internal team to address one specific Salesforce issue at a time. Managing and optimizing Salesforce in this manner leads to Salesforce processes/customization being designed irrespective of each other. It also promotes selecting a solution that fits within the budget and scope of a specific pain point, but does not consider what that solution will cost the enterprise in the long term to maintain. 

If you are a small or medium-sized business, this might not have too big of an impact. However, if you are an enterprise, this leads to two major issues. One, your internal team spends a lot of time cleaning up Salesforce and fixing issues (instead of deploying new features to deliver ROI). 

Two, it blocks organizations from deploying necessary solutions quickly and sometimes at all. New deployments depend on existing Salesforce architecture, and it is not uncommon that companies will need to complete a three-month data clean-up project before they can deploy a new platform (like a CPQ). 

Salesforce Maintenance: 5 Best Practices for Enterprises

To avoid monopolizing your Salesforce team’s capacity on fixes and stalling/blocking necessary deployments, follow the five best practices below to develop sustainable Salesforce solutions that decrease technical debt. 

1) Address Salesforce Holistically 

Departments should not request Salesforce customizations in a vacuum. This can lead to an overlap in functionality and technical debt. Adopt a “Scheduled Release Process” to address this and set the expectation that all major Salesforce updates will happen on a monthly cadence.

Have a prescribed, regular Salesforce release schedule.

This cadence should include all incoming requests being prioritized and visible across the organization. This ensures everyone understands what will be completed as part of a monthly release versus what will be prioritized in a Salesforce backlog.

Creating a monthly release schedule should be supplemented with both regular departmental and cross-departmental meetings, which act as a pulse-check on the urgency of previous requests. Sometimes priorities will stay the same, but often, they will change. Depending on your organization, hold cross-departmental Salesforce meetings bi-monthly, monthly, or quarterly. 

For more information on how to adopt a Scheduled Release Process, check out this blog: How to Create a Salesforce Action Plan

2) Opt For Scalable Solutions 

Whether you are working with a consultancy or an internal team, assess if once the solution has been implemented, how straightforward will updates be? The best solutions rely on automation, are self-serve or empower end-users. 

3) Leverage Automation and Reduce Human Intervention

When team members move on, they leave behind old processes, workflows, fields, etc. that accumulate like plaque. New employees are often not aware of what exists and if or when human intervention is required (nor do they have time to investigate). This, plus a lack of documentation, can contribute to processes breaking and technical debt. To avoid this, decrease human intervention wherever possible, rely on automation, and develop solutions with fail-safes. 

4) Leverage the AppExchange when possible 

There are many advantages to leveraging an AppExchange app versus building a custom solution in Salesforce. Anything that is custom built needs to be maintained (which requires employee time). As an example, every Salesforce release, an internal team member should evaluate all Salesforce customization to ensure the release will not break any existing functionality. 

When you deploy a well maintained app from the AppExchange, that responsibility is delegated to the creator/team behind the app. This frees up your internal team and simplifies ongoing maintenance. When evaluating custom solutions against subscription costs, make sure to quantify the hours of maintenance required annually by your internal team.

Even if a custom solution only requires 10 hours of maintenance by a Salesforce Developer a year, in wages that could cost your organization anywhere from $1,500 – $3,000 annually.

Another benefit of leveraging a SaaS solution is the regular updates and testing that occur. In contrast, often, once a custom build is complete, it is often poorly tested and never revisited for enhancements. 

5) Data Stewardship 

Often organizations underestimate the challenge of maintaining data integrity.

Data is messy, and in the absence of processes in place to decrease technical debt, Salesforce data will be unreliable.

Below are a couple of ways enterprises can manage technical debt:

  • First, ensure you have a technical debt policy and data retention policy. These help formalize the decisions that need to be made around how much data is kept and the level of effort that will be dedicated to reducing technical debt. Ideally there is also automation built in Salesforce to enforce these policies. 
  • Second, have a schedule and dedicated team members who are consistently responsible for fixing technical debt issues (this should occur weekly, monthly, or quarterly depending on your organization). There should also be team members responsible for re-evaluating legacy customization to see if an AppExchange product or a more automated solution exists.

Salesforce Technical Debt Reduction Policy template

Wrap Up 

Often solutions are built quickly to solve a pain point without considering the cost of annual maintenance. It is decisions like these that eat up team resources, stall new and important projects due to a lack of capacity, and increase technical debt. Before implementing a solution, always consider the long term cost of ownership. 

We hope this post provided actionable insight on how to reduce technical debt in Salesforce. If you have questions about this blog or how to improve your Salesforce org? Reach out today. We love helping enterprise companies with Salesforce strategic planning.

You may be interested in

Using Field Service for Post Hurricane Recovery

Using Salesforce Field Service for Post-Hurricane Recovery

CloudPower is a large electricity company that serves parts of Canada and the United States. Last year, damage from hurricanes destroyed power lines and other infrastructure, resulting in tens of thousands of CloudPower’s customers living without power for an extended period. Due to internal inefficiencies with scheduling, CloudPower could not restore power to thousands of […]

Read More

Restriction Rules in Salesforce

Restricting Sensitive Data in Salesforce with Restriction Rules

Introduction As part of the Summer ‘21 Release, Salesforce announced the new Restriction Rules (Beta) feature. This new feature provides an additional layer of security on top of the existing OWDs and Sharing Rules. It allows Admins to restrict access to sensitive records for certain users by setting up the filter conditions in the Restriction […]

Read More

Sign up for the latest tips & news from CloudKettle

Thank you for subscribing.