Admins / Platform

The Double-Edged Sword of Declarative Salesforce 

By Sasha Semjonova

What is Salesforce truly known for? If you ask me, I would say its dominance in the SaaS industry, coupled with both its community’s and the wider tech community’s vocal stance on its said dominance. One of the benefits of reporting within this space is that we truly never run out of news – for better, or for worse. 

However, at its core, Salesforce is a platform that is deeply customizable, engineered to be intuitive, and simple enough for the average tech user to master fast. A big part of this is its declarative functionality – but could the very element that Salesforce has pioneered itself on be the most prominent liability? 

What Does Declarative Mean in Salesforce? 

Declarative functionality forms an integral part of Salesforce’s entire UX and selling point. It’s the whole “clicks, not code” mantra, which means that most users of the platform can create what they need and perform the tasks they want with a drag-and-drop utility rather than making everything with code. 

READ MORE: Programmatic vs Declarative: Are Clicks Better Than Code?

The argument over which is better is notoriously heated, especially when you consider the Apex vs. Flow debate. But there is no denying that using declarative functionality, a lot of the time, is much easier. 

You don’t need to know Apex to create your workflows, and clouds like Sales Cloud and Service Cloud have a whole host of native tools to help you design, build, and action what you need without having to type out a single line of code – if you want. 

Which Is Better?

Both Pablo Gonzalez and Tim Combridge have made brilliant points in support of either side – declarative vs. programmatic – and it is evident that both have their place. Programmatic systems like Apex allow people to be specific with their designs and have the benefit of enforced basic testing, meaning that you can be confident something works before you deploy it into production. 

However, doing this can take a lot of time and a lot of skill – inciting deeper questions over Apex’s accessibility. 

On the other hand, Flow is user-friendly; almost anyone can use it and get results from it, and it can be quicker to build a flow than write out your Apex to execute the same action. 

However, as Pablo highlighted, “The best thing about Flow is that almost anyone can create a complex business process with a simple drag-and-drop UI. The worst thing about Flow is that almost anyone can create a complex business process with a simple drag-and-drop UI.”

Accessible vs. Unmanaged: Navigating the Risks

Industry veteran Matt Pieper took to LinkedIn last month to highlight the risks of declarative Salesforce, citing it as “a liability as much as it is an asset.”

This is why Pablo’s point on the accessibility of declarative tools is so important. When you make a tool or system accessible, you’re opening it up to a wider field of users who may not be as well-versed in best practices or how to build things correctly, not just build them. It is one thing to know how to build something, but a whole different ball game to know how to build it the right way.

READ MORE: An Admin’s Methodology to Debugging Declarative Issues in Salesforce

“This is what yanks my chain most about Salesforce’s sales pitch,” wrote Emily McCowan, a Salesforce CTA. “They’re so confidently wrong about how easy it is to build things. Sure, it’s easy to build the WRONG thing; much harder to build the right or least-wrong thing.”

Tom Barber, a Salesforce Product Advisor, had similar thoughts, saying absolutely everything in Salesforce should be designed before it is executed – at the minimum. 

“Just because Salesforce declarative execution can be easy doesn’t excuse skipping a 5-minute design checklist, for instance,” he wrote. “The grand irony of Salesforce compared to other enterprise-grade solutions is that sometimes it’s too easy to just execute with not a thought on design.”

Intentional building has always been a fundamental part of any Salesforce implementation, but this becomes more difficult to enforce or manage if you open up a tool’s accessibility to any and all Salesforce professionals. 

READ MORE: Designing on Salesforce: An Architect’s Guide to Making Good Decisions

Why This Is a Problem for AI 

You could argue that the minute artificial intelligence became truly accessible with the launch of ChatGPT, that was when it exploded onto the scene. From that point onwards, the digital world had changed. 

Surely, this and continued examples of AI being accessible are a good thing, and on many fronts, it is. Using AI as a tool for good has provided a multitude of benefits, and Salesforce’s research has continually provided direct examples of this. 

In a recent blog post by Mick Costigan, the VP of Salesforce Futures, he wrote that Salesforce believes that a “rising tide of accessibility – ‌abundant intelligence, expertise, and support‌ – ‌will make it easier than ever before to start and run a business.”

However, on a more granular level, this accessibility has two sides. Accessible AI means that people can achieve results from simple prompts, detailed guidance when building workflows, and increased productivity with minimal admittance issues. 

It also means that aspects such as accuracy, ethics, and mitigation are thrown into question, leaving business leaders struggling to decide how much access is really needed.

Not only that, but with tools like Agentforce that are marketed as easy to use, intuitive, and accessible, the potential to run into the problems of Flow on a potentially significant scale increases. 

Because “anybody can build an agent,” according to Salesforce, but can anyone build agents that do not produce hallucinatory answers, follow best practices, and adhere to necessary permissions, security limitations, and relevant actions? Maybe not.

Final Thoughts: Why This Conversation Won’t End

The clicks vs. code conversation is one that will never end, especially as either side debates over which method is more efficient, accurate, and customizable. Matters and opinions are always changing, too – Alex Edelstein, the SVP of Product Management at Salesforce, recently told Salesforce Ben that he thought Salesforce Flow is “still too hard”, indicating how wildly perspectives differ across the board. 

Something that has never been more relevant, though, is the conversation around security and access when it comes to Salesforce, especially in light of the continuing breaches. Sometimes having an accessible tool or technology is the best possible solution, but it doesn’t come without its risks. Businesses that want to make the most of declarative functionality should not do so without appropriate guardrails and governance – keeping employees from producing blindly, and minimizing fallout across the board. 

You can find out more about the best practices for approaching solution design here

The Author

Sasha Semjonova

Sasha is the Salesforce Reporter at Salesforce Ben.

Leave a Reply