What is Technical Debt?
If Dr. Frankenstien were a Salesforce admin, technical debt would be his most monstrous creation. Technical debt is often the “hacky” customization added on the whim of one department (or demanding person). It ignores the needs of the company for the whims of the few – potentially slowing down operations, degrading scalability, jeopardizing stability, and creating security risks.
Like Frankenstein, technical debt is slow, clunky, and pretty scary from a security perspective. This is especially true in the healthcare industry, where speed and efficiency save lives…and where the most benign misconfiguration can expose sensitive PHI.
Simply put, Salesforce technical debt is any rule, flow, dashboard, data, code, or app you don’t need…and it impacts every part of the healthcare organization, including revenue, development, regulatory, operations, and clinical departments.
Technical debt can live in the open or the darkest shadows of your Salesforce organization…let’s look at the most common examples.
Examples of Salesforce Technical Debt
The most common examples of technical debt we see in our new client’s Salesforce environments include hard-coded references, unused validation rules, inactive workflows, outdated dashboards, and legacy applications. Unfortunately, each carries risks (and rewards for removing them).
Hard-coded references
A hard-coded reference generally means a link that contains the name of your Salesforce instance…for instance, using na1.salesforce.com instead of <yourdomain>.my.salesforce.com.
This is particularly dangerous when performing an instance refresh or migrating to a new organization. It’s likely that integrations, emails, knowledge base articles, and other customizations will be interrupted if you use hard code references.
Salesforce offers an excellent guide for finding hard-coded references here.
Unused validation rules
Validation rules are vital to keeping your data clean. Sometimes, you must be strategic with them – your Salesforce license limits how many can be active. Unused validation rules add clutter to your Salesforce org.
Unused flows and workflow rules
Like validation rules, the Salesforce edition you’re on limits the number of active flows. Likewise, it’s crucial only to retain valuable flows.
Unused Reports and dashboards
Old reports referencing bad data plastered on outdated dashboards will confuse sales, operations, marketing, and leadership teams. Therefore, it’s essential to routinely remove access to inactive reports and ensure you’ve empowered users to use the new ones consistently.
If you’re looking to clean house, Salesforce outlines steps to finding unused reports and dashboards here.
Legacy or unused apps
Most Salesforce environments probably have unused apps running in the background. Not only can they slow down performance…they also introduce security vulnerabilities.
The practice of “App rationalization” is a great way to solve some of these issues in a Salesforce environment. It’s a process that audits existing Salesforce apps to discover which should be kept, retired, or replaced. Because it often eliminates redundancies and improves performance, app rationalization can generate significant cost savings on licenses, upgrade costs, and more.
Calculating the Cost of Salesforce Technical Debt
Calculating the cost of technical debt is pretty tricky – and it demonstrates the different goals between revenue and technical roles.
Revenue-driven roles are primarily interested in growth. Many perceive “growth” as feature creation, not elimination. This means technical debt gets ignored in favor of new development.
However, this is short-sighted.
Consider how much is being spent on:
- Staff needed to maintain a larger codebase
- The license cost of deprecated features and unused apps
- Training costs of new employees to maintain legacy code
- Operational costs associated with poor performance
- Storage costs associated with unused data
- Database costs related to patients, leads, or partners
…it’s clear that technical debt inhibits growth, so spending the time and resources to eliminate it is a growth-driven strategy.
Final Thoughts
A certain amount of technical debt is acceptable, but it needs to be addressed on an ongoing basis proactively. Demonstrating the cost of technical debt makes it easier to justify the work and time required to remove it from the perspective of ROI and risk mitigation.
If you’re a healthcare organization looking to eliminate technical debt, improve efficiency, and reduce license costs, we’re here to help.