15 Best Practices In
Salesforce Development

Introduction: -

Many businesses have decided to use Salesforce's customer relationship management solution. Over the past few years, there has been a dramatic increase in the number of people using Salesforce, which has propelled the company to be one of the enterprise software vendors currently experiencing the most significant rate of expansion.

If you want the best possible results from your Salesforce implementation, you must adjust as your company grows and its business needs shift. When developing new functionality for Salesforce or customising the features, there are many factors to consider.

The out-of-the-box capabilities of Salesforce deliver a plethora of cutting-edge features that make it easier for contemporary businesses to fulfil their operational requirements. These capabilities help modern organisations meet the demands of their customers. Although many companies can generate value with these features, others must develop and customise the solution further to better meet their unique business goals.

When done correctly, Salesforce development can enable companies to build specific features, services, and applications into the Salesforce platform while easily and quickly achieving their business goals. Taking advantage of the solution's multi-tenant architecture and integration capabilities, businesses can customise it to create outstanding elements that benefit the company.

Notable Facts About Salesforce: -

• More than 150,000 businesses use Salesforce, generating $21.25Bn. In revenue in 2021.
• The market share of Salesforce CRM is 19.8%. It is higher than the combined share of the top four competitors.
• Salesforce has more than 56.000 employees globally.
• The revenue of Salesforce has consistently grown in the last twenty years at a CAGR of 51.22%.
• The Salesforce subscription and support division contributes to 93.99% of the overall revenue worth $19.98Bn.

Benefits of Salesforce Development: -

• Build user-friendly applications and modules that technical and non-technical users may easily traverse with drag-and-drop functionality.
• Integrate features and capabilities that can be customised for teams and departments and enhance workforce productivity.
• Salesforce Cooperation Cloud improves communication and collaboration through updates, projects, and bottlenecks.
• Create functions that address customer questions, requirements, comments, and deliveries to improve your relationship with your customers.
• Utilize the built-in analytic capabilities to your full advantage to generate predictive reports covering organisation development, the status of competitors or markets, and brand reputation.
• Enable Salesforce integration with pre-existing enterprise systems and applications that will be developed to improve overall business performance.

Best Practices De-Coded: -

• Develop A Complete Plan – It is a no-brainer that without a well-thought plan, success is not possible. It is in your best interest to have a well-thought-out strategy outlining how you intend to build and roll out your solution before starting the Salesforce development process. Planning allows you to understand where you are in the process, where you want to get to in the future, and what steps you need to take to get there.
• Uncover The finer nuances of Salesforce Architecture. After establishing a road map, it is an excellent idea to understand the Salesforce architecture, which includes the various layers, the interactions between them, the different components, APIs, and databases. In addition, it is essential to have a solid understanding of the distinctions between the fundamental capabilities of the platform and the pre-packaged applications that run on it, as well as the communication and data flow between the various servers.
• Explore and Exploit The Test Environment. Although Salesforce does provide the option of developing modules and customising features in a live environment, it is recommended that the sandbox be used for development because it will not impact the performance of your system. You can use the developer sandbox to create new features, the partial sandbox to determine how the development process might affect your system, or the full sandbox to deploy customisations and determine how they will operate within your system.
• Ensure Consistency in Coding - Because it is only natural to have multiple developers working on your Salesforce development project simultaneously, adhering to a consistent coding style can help ease the development process significantly. Adhering to standard coding conventions can not only pave the way for establishing legal guidelines but can also add consistency, ensuring that all team members reach the same conclusions regarding standards and patterns and adhere to the same principles.
• Utilise Salesforce's built-in Trigger Frameworks - The use of trigger frameworks can help significantly reduce the amount of time and effort spent developing software, which is especially helpful as your requirements expand. They make it possible to remove logic and ensure consistency across the platform, making unit testing, integrating changes, and maintenance much more straightforward. Once standardised, you can be sure that all your triggers work consistently, giving you complete control over the order in which operations are carried out.
• Embrace a Modular Approach to Your Salesforce Development. The ability to develop functions or modules in isolation from one another is one of the most significant benefits offered by Salesforce development. You can design the system in such a way that its various functions can be optimised independently if you take a modular approach and do so. This is possible because the failure of one part will not influence the other processes.
• Deploy Appropriate Tools - In addition to selecting the appropriate features, it is also essential to use the proper tools for development. This will allow you to begin developing and testing your Salesforce platform as soon as possible. Conduct a thorough analysis of the tools at your disposal, considering the requirements you have specified, and select the ones that will assist you in efficiently meeting your needs.
• Refrain from DML/SOQL Queries - There will be times when you want to insert/update multiple records simultaneously and query sets of documents based on specific contexts. While iterating through the forms using the loop, you might feel tempted to perform a query or DML operation on these records. After all, what's the worst that could happen? Well, quite a lot.

  Both SOQL and DML are some of the most expensive operations that can be carried out within Salesforce Apex. As a result, governor limits for both processes are highly stringent. Therefore, placing them in a loop is a recipe for disaster because we can quickly and unknowingly reach these limits, particularly when triggers are involved in the process!

  When it comes to DML statements, we have the option of moving those statements outside of the loop. In their place, we can add the records we want to perform those operations on to a list within the circle and then run the DML statement on the list rather than the records themselves. This is the most prudent course of action to take in many circumstances. Moving SOQL to a position outside a loop can be more challenging because the decision depends heavily on the context.

• Only Hard-Code IDs When Needed - When IDs are hardcoded, they may function correctly and without incident when they are being developed; however, as soon as our code is migrated into production, those IDs will no longer reference the appropriate record. This is especially true for Record Types that were initially developed in a sandbox environment and later transferred into a production environment. Consider the opposite scenario: if we create a sandbox from production, our hard-coded identifiers will no longer point to the appropriate records.

  If we want to use record types, we can instead make references to them using their Developer Name, which will remain the same across all environments. Suppose the ID we want to use is associated with a particular record. In that case, we can store this ID within our custom metadata and retrieve the value during runtime. This allows the developers to freely alter the value depending on the environment in which the code is being written or the requirements imposed on us.

  There is only one situation in which we are not required to adhere to either of the two methods described above, and that is when we are explicitly referencing the Master Record Type. This record type is the default and is consistent across all instances. On the other hand, the fact that it is static right now does not guarantee that it will remain so in the future; consequently, we ought to store it probably also in custom metadata (if doing so is necessary) to be on the safe side.

• Declare Openly the Existence of a Sharing Model - When we start writing brand-new code, one of the very first things we should do is declare our sharing model. This is one of the most important things to do. When we want our code to enforce sharing rules, we must always advise that, but when we want it to bypass record access, we must always say that it is not sharing. Developers often find themselves skipping this step.

  Declaring our sharing model explicitly enables us to communicate our goals to anyone else who may work on our code in the future. This includes anyone who may work on our code. If we omit this, it will make it more difficult for them to comprehend what is going on within the code; on the other hand, if we include it, they will have a much easier time understanding it.

  You can safely omit only if your code does not perform any DML or queries. This is the only time it is safe to do so. However, if this is possible, or if you want to play it safe, it is wise to declare the sharing model anyway, specifying it as 'inherited' to allow a consumer of your course to control the model instead. Declaring the model in this manner will enable you to play it safe.

• Use Only One Trigger Per Single Object Type - The principle of using only a single trigger for each object is ingrained in the minds of many programmers. This is because the focus is both simple to remember and straightforward to put into practice. But why is this relatively straightforward "best practice" such a significant one to adhere to?

  The order in which individual triggers are executed cannot be guaranteed when multiple stimuli are defined on a single object. When a record is saved and the triggers are invoked, the order in which the individual triggers are executed is utterly arbitrary for all intents and purposes. It's not uncommon for the individual actions that make up a trigger to have their order of priority, or they might have a condition that requires an initial step to have been finished before they can proceed (e.g., assigning a parent lookup which is then expected to be populated in the following action).

  An entirely random trigger order also introduces randomness into our code. This randomness makes it more difficult to debug and develop code because there is always some element of randomness present, and we cannot accurately replicate scenarios.

• Test Multiple Scenarios - When it comes to testing, having a high number of lines covered by tests is a good goal, but it does not tell the whole story. Salesforce mandates to have at least 75% code coverage whenever you wish to deploy Apex code into production.

  You are writing tests solely to meet the code coverage requirement, demonstrating that your code has been executed and doesn't provide any value other than showing that in a particular scenario. It might work or might not when deployed in real-time.

  When writing our tests, we should worry less about code coverage and more about covering different use cases for our code. This will ensure that we protect the scenarios in which the code is being executed. This is accomplished by writing multiple test methods, some of which may be testing the same and not generating additional covered lines. Each test method executes our code by a distinct scenario, allowing us to test the system effectively.

  One possible application would be to cover both positive and negative test cases in a trigger. After the tests run, the next step is to verify that the code has successfully carried out the intended action; if it hasn't, we want to fail the test manually. If the code hasn't successfully acted, we want to forget the test manually.

  Writing tests for code coverage isn't the only reason to run these kinds of tests; they can also serve as an early warning system for problems that may crop up if an administrator adds some new functionality or a different section of code is modified. This testing offers much more value than just writing tests for code coverage. Testing for these scenarios ensures that we are alerted about the issues and can resolve them (before they hit production and cause late nights!). Testing for these scenarios also ensures we don't miss any opportunities to save money.

• Double Check Tests - The quality of the Salesforce solution you develop is directly proportional to the amount of testing you do. You must test the platform’s functionality to ensure that it can meet the requirements of your client, who will use it daily. Try every functionality and feature you've developed to ensure that it functions as intended in any circumstances.
• Keep Documentation Clean and Complete - When developing a solution for Salesforce, it is also a good practice to document everything that programmers are working on. This can help avoid any misunderstandings. This practice, which entails keeping a log of every development effort, can assist other administrators and developers in comprehending the advancements that have been made, as well as preventing those advancements from being duplicated or altered when they should not be.
• Avoid Business Logic In Triggers - When we write triggers, placing our logic directly in the trigger becomes very difficult to test and maintain the triggers. It would help if you used classes designed to handle our senses. These classes can then be easily tested, kept, and reused. These classes are typically referred to by their shorthand name, TriggerHandlers.

  These TriggerHandler classes take the inputs provided by the trigger and then, as a final step, call the specific courses that hold the business logic we have written. They can be as straightforward as updating the handlers to name the new code as we add it, or they can be as intricate as utilising things like custom metadata types to allow admins to configure our triggers in various ways.

  However, it is a common mistake to put your logic and functionality directly into a TriggerHandler or TriggerHelper class. This can lead to unexpected results. It is recommended that separate categories be created for each piece of functionality and that the TriggerHandler be the one to invoke these classes.

  If we do not follow this procedure, we will very quickly produce code that cannot be maintained. This violates the "Single-Responsibility Principle" because it causes it to do everything about an object's trigger actions, which results in the creation of a "God object," which is an anti-pattern.

  Suppose an object's trigger is exceptionally straightforward (for example, it only invokes a single action). In that case, it may be appropriate to forego a handler class and instead make a direct call to the action invoked by the trigger from within the spur itself. However, the steps should be written with a handler in mind and migrated to a handler as soon as the complexity of the trigger increases.

Concluding Remarks: -

Implementing industry standards and best practices is essential to any solution provider’s core capabilities. For excellent results out of your Salesforce Development initiatives, it will be beneficial to understand the why and the what of the development process. This will enable us to make more educated and intelligent decisions regarding our choices' potential short-term and long-term effects.

DivIHN Integration Inc. offers seamless, robust and scalable Salesforce solutions. For more information, please get in touch with Kannan Venkataraman at kannan@divihn.com.