Clicks not code; the mantra of Salesforce. This phrase has been banded around the Salesforce ecosystem for years now, but has it been detrimental to the ecosystem and how organizations have utilized Salesforce?
This article explores various perspectives on this topic, considering the advantages and disadvantages of the “clicks not code” philosophy in Salesforce development. An intriguing topic with diverse opinions, this article sheds light on the nuances organizations face when deciding the best mix of clicks and code for their Salesforce implementations.
What Do We Mean By Clicks?
First off, what is meant by clicks? Clicks, or declarative programming, emphasizes the ability to configure and customize the Salesforce platform using its declarative tools rather than writing custom code for every modification.
Clicks often refer to the actions performed through the Salesforce user interface by clicking and configuring settings using the point-and-click tools available in the platform. This includes setting up fields, defining page layouts, creating workflows, and configuring other elements without the need for coding. There are many declarative tools within Salesforce including Flow Builder, page layouts, Lightning record pages, validation rules, and assignment rules.
Clicks are like using a microwave to heat a pre-packaged meal. You press a few buttons, set the timer, and your meal is ready in a short time. It’s convenient and doesn’t require much cooking knowledge, but your options are limited to what’s available in the package.
Flow Builder has come on leaps and bounds over recent years. With so many different flow types to choose from, and so many different capabilities within the tool itself, it really is light years away from Workflow Rules or even Process Builder. The fact that you can use this one tool to create guided wizards that enable you to guide users through a series of screens to perform various actions shows how versatile Flow Builder has become.
What Do We Mean By Code?
Code, or imperative programming, typically refers to the use of programming languages to create custom functionality, automation, or business logic. The main programming language used for coding in Salesforce is Apex, a strongly typed, object-oriented programming language that’s similar to Java.
Apex can be used to create custom business logic, manipulate data, integrate with external systems, schedule jobs and batch processes, implement unit tests, and enforce business rules (plus much, much more).
Other coding languages used to customize Salesforce include:
- Visualforce (for creating custom user interfaces and designing pages with custom functionality)
- JavaScript and XML (used for creating Aura Components and Lightning Web Components)
- HTML (used for creating Lightning Web Components)
Back to our kitchen analogy, consider code as being in a fully equipped kitchen. You have all the ingredients and tools to create a custom dish from scratch. This offers endless possibilities, but it takes more time and skill to prepare the meal because you need to follow a recipe and understand the cooking techniques.
Time
The main problem with both of these approaches is time.
With declarative programming, such as Flow Builder, it takes time to build a complex flow. Creating the resources, putting the elements together, testing the functionality, and documenting the process, all take time. There are occasions where you would need to read through 30-plus elements on a flow, which would only be 10 lines of code if done using Apex.
With imperative programming, the question of time is much more simple. It takes a lot longer to learn how to read and write code than it does to create a flow. You could build a very simple flow in a matter of minutes that will perform some basic functionality. For the majority of admins you don’t need to understand what is going on behind the scenes with a flow, whereas that simply isn’t the case for developers when writing Apex.
You need to know the fundamentals of the platform including the architecture and data model, Apex itself in how to write, test, and deploy code, how to use SOQL and SOSL to retrieve and manipulate data, the various development tools available to you such as the Developer Console, VS Code, and Code Builder, the list goes on.
A Personal Example
Let me give you an example to illustrate the above. In a previous role, I was a solo admin. There was a requirement for me to build some automation between the Assets object and a custom object. There was a junction object and master-detail relationships involved, I won’t go into the details but it was a complex configuration.
It was a complicated thing to build using Flow Builder, and ended up being done using a scheduled flow. Although it worked most of the time, it wasn’t the best experience and sometimes it didn’t work on certain records. Luckily, the times it didn’t fire, it was straightforward enough to intervene manually.
A few months later we hired a Salesforce developer because our org became more complex. The first task I asked him to help me with was to automate this using Apex. He built a fully working solution in a few hours and we never experienced any issues with this again.
The urgent time restriction in getting something in place meant I wasn’t able to take the time to learn how to build this using Apex, which ultimately was the right approach.
Journey to Salesforce Program
As mentioned in Journey to Salesforce: Fast Track to Becoming a Salesforce Developer; there is an insatiable demand for developers as Salesforce becomes a vital part of an ever-increasing number of businesses. Because of this, Salesforce has created the Journey to Salesforce program, a free & online program for people in the US, Canada, or India, with the sole aim of bringing more Salesforce Developers into the ecosystem.
This begs the question, would there be such an insatiable demand for Salesforce Developers if the “clicks not code” message wasn’t pushed as hard as it has been? Would more admins have gone down the developer path if there was more of a push to learn Apex? Would there be a need for programs like Journey to Salesforce?
Will AI Muddy the Water?
The introduction of both Einstein for Developers and Einstein for Flow sparks intriguing considerations regarding their potential overlap and application scenarios. Focusing on the specific scenario of creating a new flow, users face two primary options: Einstein for Flow and Einstein for Developers.
Einstein for Flow caters to a broad audience, enabling admins to articulate flow steps in natural language without coding expertise. In contrast, Einstein for Developers, with its generative AI, assists developers in crafting Apex code, particularly for intricate flow logic.
When deciding between the two, various factors come into play. Firstly, user expertise plays a crucial role, with Einstein for Flow being ideal for admins or developers seeking a quick, code-free approach, while Einstein for Developers suits those comfortable with Apex coding.
Flow complexity is another consideration, as Einstein for Flow handles basic and intermediate steps efficiently, whereas Einstein for Developers offers more control for intricate logic and integrations.
The desired outcome and development time further influences the decision. Einstein for Flow prioritizes rapid automation with limited customization, making it faster for basic flows, while Einstein for Developers allows precise tailoring of logic but may take longer initially, proving efficient for complex flows.
Ultimately, the choice depends on a combination of factors like user expertise, flow complexity, desired outcome, and development time constraints. Users may even opt for a hybrid approach, integrating both tools within a single project for a balance between simplicity and sophistication. It’s essential to acknowledge the learning curves associated with each tool and stay attuned to their evolving features over time.
It is also worth noting that at this moment in time, only Einstein for Developers is generally available for customers, with Einstein for Flow reportedly becoming generally available in Spring ‘24.
So, Are Clicks Better Than Code?
One of the things I say most often in the Salesforce ecosystem also applies here; it depends. The “clicks not code” mantra hinges on a multitude of factors that collectively influence its applicability and effectiveness. The decision to prioritize clicks over code depends on the complexity of the customization needed, the skill set of the user, and the specific requirements of the project. A one-size-fits-all approach simply doesn’t work.
For straightforward configurations and rapid implementations, the clicks approach proves efficient, offering a user-friendly experience without the need for coding expertise. However, when faced with intricate processes, nuanced automations, or the demand for highly tailored features, the limitations of the clicks approach become apparent.
In such cases, factors like the learning curve associated with code, the need for advanced functionalities, and the project’s long-term scalability may lead users to opt for a code-centric approach.
In essence, the choice between “clicks not code” rests on careful consideration of the project’s unique requirements, striking a balance between simplicity and the ability to meet complex customization needs.
Summary
In summary, the debate about “clicks not code” in Salesforce revolves around two ways of customizing the platform: the easy but sometimes slow “clicks” method and the more complex but powerful code method.
The Clicks approach allows you to personalize Salesforce through a straightforward process of clicking buttons and configuring options, greatly reducing the need for coding. While it is efficient for simple tasks, tackling more intricate customizations like advanced Flows may be time-consuming. Conversely, the Code approach entails crafting computer instructions to implement tailored features, offering greater potency. However, mastering and utilizing code requires a more substantial investment of time and effort.
Time is a big deal here. Clicks are fast but might take a while for complicated tasks. Learning to code takes longer, but once you know it, you can do a lot more. The big question is whether the strong push for “clicks not code” has led to a high demand for professional coders, like the ones trained in programs such as Journey to Salesforce.
With the introduction of AI tools like Einstein for Developers and Einstein for Flow, there’s an added layer of choice. Admins need to decide if they’ll stick to the easy tools they know or venture into coding for more advanced solutions.
In the end, the debate about “clicks not code” is like a journey. It’s about finding the right balance between easy but limited clicks and complex but powerful code. The future might see a mix of both, influenced by new technologies like AI that shape how people work with Salesforce.
Comments: