Admins / Developers / Platform

Programmatic vs Declarative: Are Clicks Better Than Code?

By Andrew Cook

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.


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.


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.

The Author

Andrew Cook

Andrew is a Salesforce Technical Instructor at Salesforce Ben. He is 14x certified and has worked in the ecosystem for 12 years.


    January 17, 2024 6:33 pm
    Thanks Andrew for diving into this important topic and most of us in the Salesforce Architect business surely wholeheartedly agree with you that 'it depends'. While your article mainly focused on 'Time' as one of the deciding factors, I can't help but wonder how your article might change if aspects like 'generated business value', 'scalability & maintainability' and 'leveraging standard features' are considered as well. As solution architects we typically determine options and the 'best' solution based on the following questions: - What's the actual business value that an organisation wants to generate? How does the value relate to the ease of implementation and upkeep of the future solution? - What are the business processes that will support this and how might a new functionality (e.g. Flow) fit into them? - How well can the intended functionality and the desired outcome be described, are acceptance criteria and test criteria clear? - What standard functionality can be leveraged for this? Does it already exist or is it on the roadmap? - In case the functionality does not yet exist (e.g. the use case that you described above), is it worth to wait for it to become availability, because it's already on the roadmap, or can it be developed (via custom code) it a way that it can be easily replaced once the standard functionality has been made available by Salesforce? - How well is the organisation prepared to later on keep the custom code alive and extend it, is the organisation aware of the custom code development guidelines and best practices? Are they dependent on external resources for maintenance and error handling? As you said 'it depends' and very often the sentiment will be 'We can do it, but should we really do it?'. As we all agree that it's never just an 'either or' question but rather a holistic view at all the pros and cons that will allow an organisation to make a really well educated decision. Views expressed are my personal views, based on having been a Functional Consultant / Solution Architect / Business Analyst for over 20 years now and having seen firsthand how organisations invest in so called Standard (pre-built) Software (CRM, ERP, SCM, etc.) and then,years later, struggle to innovate and grow further after having gone down the 'easy & quick' route of custom code development.
    Andrew Cook
    January 18, 2024 10:09 am
    Hi Claudia, Thanks so much for your thoughtful comment! I really appreciate your extensive insights as a seasoned professional in the field. Absolutely agree with everything you've highlighted, especially the crucial considerations around business value, scalability, and leveraging standard features. Your questions are spot-on and reflect the comprehensive approach needed in making these type of informed decisions. In this particular post, I honed in on the time aspect as I felt it's a facet of the discussion that hasn't received as much attention. Not to say the other factors aren't crucial – they absolutely are! It's just that I wanted to explore the time dimension and its impact on decision-making.
    January 18, 2024 11:11 am
    I agree with Claudia. While " Click or Code " is a very important question, many other considerations exist. In enterprise computing, I would add "Who's gonna maintain the feature?". I have seen customers with lots of code and few developers gone "elsewhere" or nobody left to maintain old code / no reel documentation... In a nutshell, I'm very careful before pressing the "magic code" button. I do see Salesforce as a SaaS/config platform first. But it may be just me? Great article anyway. Thanks for writing it. Fabrice
    January 18, 2024 2:52 pm
    One question i've wondered is, how fast/efficient is code vs clicks? I have a flow that operates over 2k+ records, and it gets used often. I've wondered if offloading some of the heavy lifting to code would speed up the performance on the flow. Any thoughts on this?
    May 22, 2024 12:22 pm
    Have you also thought about the aspect of whether Apex Triggers already exist? In this case, it can be very unfavorable to create a record-triggered flow with “Clicks”, even if the flow is built straight forward fast. In the worst case, the flow calls the Apex trigger again via a record update - not only is this inherently bad design, you also reach SOQL limits etc. very quickly.

Leave a Reply