“Clicks vs Code” is a common discussion topic on the Salesforce platform and there are many things to consider when approaching the conversation. The wrong approach can result in a solution that is difficult to update and maintain. Before we dive into how WillowTree approaches the topic, let’s start with what we mean by “Clicks vs Code.” In the context of Salesforce, there are two ways to program the platform.
Both types of programming are powerful and can be used to meet your business needs. Both also come with potential drawbacks. So how do you know which is right for you? At WillowTree, we work closely with you and your team to understand your business, your goals, and your challenges so we can recommend and implement solutions that meet the challenges of today and set your business up to meet the goals of tomorrow. In this article, we provide a deeper look into how WillowTree approaches “Clicks vs Code” to deliver the right solution for you.
The complexity of a solution is driven by a number of factors such as the number of objects that make up the solution, required external API integrations, and algorithms. We work with the business to gain an understanding of what needs to happen and when. Once we understand the business goals, we weigh the potential tools against the complexity. For example, perhaps some math is required in a field. We can assess solutions by asking questions like does that object have access to all the data it needs? Will using something like a Formula run into any character limits? Does a Rollup Summary field make sense? Do we have the correct object relationship models in place? Answers to these questions help us recommend solutions that accurately and efficiently meet the complexity of the business need.
Being a multi tenant cloud environment, Salesforce enforces a series of governor limits on platform transactions. Respecting these limitations can seem straightforward, but things can get tricky when the size of the data involved and the scope of an entire transaction are assessed. For example, let’s say an update operation needs to happen on each of the 10 Line Items on a Quote object when a field on the Quote object changes. What happens when the solution makes it to production and our test case of 10 Line Items becomes 100? Or maybe 1,000? Can our solution scale to the production data? In addition to the size of the data the scope of the transaction is important to understand. Using the same example, what if the Line Item itself has an update trigger, a Process or Flow on it? Or all 3? When we update 1,000 Line Items, each will go through these as a part of the original transaction. Will these added contributions cause us to exceed any Governor limits? Understanding the data size and scope of a transaction helps us identify a performant solution and one that can be confidently tested against.
Meeting the business needs is important for any solution. Perhaps just as important to consider is the scalability of a solution over time. It’s possible using a Flow meets the needs today, but we know the business has plans to expand the functionality. Will the Flow still meet these needs when changes are needed three months from now? This question is important as its answer can save time and rework down the line. We know things change, making the future sometimes unpredictable, but whenever possible it’s important to us to know where our clients want to take their business. This insight allows us to recommend solutions that align to the short-term goals and can elegantly scale with the long-term goals.
The right solution can vary based on the needs of each client. For example, it may be very important to a business to have a view that aggregates data from multiple objects. In this scenario, Lightning Web Components may be an option or an entirely custom Visualforce or Lightning page could be recommended. On the other hand, it may not be as important to another business that multiple object data be presented in a single view. In this case, a series of intuitive Lightning Record Pages with Related Lists using out-of-box functionality may meet the business needs and more time can be devoted to other features.
Another way we reflect on the needs of our clients is in understanding the capacity and capability of maintaining the solution over time. If a client has a dedicated Salesforce development team, custom solutions may be easier to transition and maintain. If a client only has a team of Admins with minimal development experience, it may make more sense to put extra emphasis on finding no code solutions where appropriate. In either case, we are constantly looking for ways to empower our clients. One way we do so is ingraining configuration into our solutions. Whether via the use of Custom Settings or otherwise, we give the control to the Admins to easily configure without reliance on deployments.
Utilizing the out-of-the-box tooling that Salesforce provides can move a solution to production quicker. This can be a great option as it can reduce development time and the overall timeline. When we consider using out-of-the-box tools, we consider all factors outlined above. If the solution makes sense in the context of those items as well as speed to market, then we believe there is no need to reinvent the wheel. The efficiencies gained can allow the team to bring features to market quickly and then move focus on to other areas of the application.
Last but certainly not least, it’s important to take the end result for the user of the platform into consideration. There are various impacts to UI/UX that can diverge based on decisions made regarding architecting and developing Salesforce solutions natively or via custom code. Although from a technical perspective it might make sense to minimize custom development, in scenarios where it can make a large impact on the time it takes to execute a process, or the look and feel of the application, it is important to consider what impact this could have on user adoption. A multi-step screen flow may be ‘easy’ to configure in Salesforce, but if the flow takes 20 clicks through multiple screens to complete, it might not necessarily be better for the user when compared to a code solution that could speed up the time to complete and the number of clicks necessary.
Building a Salesforce solution that meets the needs of your business today and beyond can be challenging. The team at WillowTree is equipped for the challenge and can provide solutions that consider all of the relevant factors. Get in touch today to take the next steps.
Please contact us to discuss your Salesforce or MuleSoft needs.
