What is Salesforce Tech Debt? And How Can You Reduce it?
What is Salesforce Tech Debt? And How Can You Reduce it? RevOps 10 min In a recent statement, Salesforce disclosed its intention to raise list prices across several product offerings, including Sales Cloud, Service Cloud, Marketing Cloud, Industries, and Tableau, with an average increase of 9%. Starting in August 2023, the revised list prices for certain Salesforce products will be implemented, targeting new customers and existing customers acquiring additional cloud services. Salesforce has outlined the following adjustments in pricing for their fundamental Sales and Service Cloud offerings: Professional Edition will increase from $75 to $80 Enterprise Edition will increase from $150 to $165 Unlimited Edition will increase from $300 to $330 These changes are going to affect a lot of organizations. Over 150,000 companies across industries use Salesforce. With specialized solutions for operations across sales, service, marketing, and commerce, it is no wonder that the hike in price would affect almost every industry. For companies using Salesforce, the major concern is: Salesforce Tech Debt. What is Salesforce Technical Debt? Technical debt refers to the expense of having to do extra work later on due to opting for a quick solution in the present rather than investing the time in a more optimal approach. This concept is also commonly referred to as “Shift Left,” which emphasizes the idea that the sooner you identify and address issues, the more cost-effective it is to resolve them. Technical debt represents the additional effort required to rectify a hasty, less-informed solution chosen in the present (constructed quickly without a deep understanding of business requirements), as opposed to adopting a more time-consuming but superior approach. In a broader sense, technical debt encompasses any customizations, whether through code or declarative means, that were implemented when standard functionality wasn’t suitable or accessible. Technical debt can also contain situations where solutions were initially designed for a specific purpose, but as business needs evolved over time, small adjustments were tacked on. A more constructive perspective on technical debt is to recognize that virtually everything can be considered a form of technical debt, but it’s termed “debt” because it necessitates future efforts to address and resolve. In the past, technical debt was primarily associated with developers taking shortcuts in their code. However, in the era of low-code platforms such as Salesforce, technical debt can arise not only from coding decisions but also from the configuration choices made through user-friendly “clicks” within the platform. What Causes Tech Debt? Salesforce technical debt arises from rushed or suboptimal development practices, including quick fixes, inadequate adherence to best practices, complex customizations without proper planning, and neglect to update and adapt solutions over time. This debt accumulates when shortcuts are taken, making future maintenance and scalability more challenging and costly. Here are a few factors that can cause technical debt: 1. Modified or outdated design This occurs when the business requirements change, rendering certain functionalities unnecessary. However, it’s often deemed safer to retain these functionalities. 2. New releases This arises when the introduction of new platform features surpasses the capabilities of previous releases or custom development efforts. For instance, Salesforce Flows are taking precedence over process builders and workflow rules. 3. Intentional technical debt When a deliberate decision is made to expedite development, fully aware that it will entail higher long-term costs, but it’s considered the appropriate course of action. 4. Unintentional technical debt Accumulates when shortcuts are taken for various reasons, typically due to time constraints or concurrent workstreams. 5. Tacked-on technical debt Occurs when a particular functionality is continually extended incrementally and “bolted on” to maintain its functionality rather than undergoing a proper reconstruction. Up to this point, we’ve delved into the theoretical aspects of technical debt, discussing its causes and mechanisms. However, what does it actually manifest as in real-world scenarios? Let’s have a look: Common Forms of Salesforce Tech Debt Common forms of Salesforce technical debt include the accumulation of unused customizations, outdated roles and permission sets, complex and undocumented workflows, inadequate data modeling, and the absence of thorough testing. This technical debt arises when shortcuts are taken or best practices are overlooked during Salesforce development, making the system harder to maintain and optimize over time. Several prevalent forms of technical debt can be identified In Salesforce, including: 1. Visualforce component vs sales path Before the introduction of Sales Path, organizations required a visual means to depict the progress of an opportunity stage or process. To achieve this, they had to customize a Visualforce component. However, with the release of Sales Path by Salesforce, these visualizations became standardized, which subsequently led to an increase in the technical debt interest rate. 2. Adapting process automation The creators of 10K recognized the necessity of automating their invoice generation process. They initially developed an hourly function to create invoices, incorporating some basic rules. However, as their contract structures evolved, they found themselves adding more functions to their initially straightforward task. Managing these changes became increasingly challenging, prompting them to allocate time to rewrite the process based on the current state of their business operations. 3. Excessive customization As previously mentioned, Salesforce provides a user-friendly environment for creating custom Objects and code, even when a simpler declarative solution would suffice. For instance, opting for a workflow instead of resorting to triggers for scripting tasks. This form of technical debt often arises from an overly responsive approach, where every requested change is implemented without exploring alternative options within standard configurations. 4. Unused customizations Despite being promoted as a ‘no-code’ platform, Salesforce cannot handle every task declaratively. Changes in business requirements may render customizations that were once essential unnecessary. Unless these customizations are retired, they can introduce inherent complexity to every new change and potentially hinder end user adoption by making your Org more challenging to navigate. 5. Access controls You’ve likely encountered the concept of “the principle of least privilege.” On the flip side, we have the “principle of most privilege,” where users end up with excessive access as their roles within the organization evolve. While other forms of technical debt can impede progress, retaining unused profiles and permission