Declarative Programming in Salesforce – The Power of “Clicks Not Code”
In this article, we’ll explain how you can program without knowing a programming language with Salesforce’s “Clicks Not Code” in their Lightning Flow Builder tool.
It’s 1998, you’re at your cubicle and your co-worker says he has been assigned the task of designing an automated system that scans live data and acts upon it intelligently. He tells you he is going to do it all without writing one line of code. You would call him crazy and ask for his resignation. Jump ahead 10 years to 2008 and you would likely approach it the same way.
But in today’s age of technology, the idea of declarative means of programming are not so farfetched. An administrator can now handle these types of requests on their own, without any advanced development experience.
With tools like RPA & AI quickly advancing, these types of approaches are becoming more common, however Salesforce has been a bastion at the forefront of what they call “Declarative Programming” for quite some time.
Their tag “Clicks Not Code” was something I tested to its full extent recently, and it proved to be a successful, reliable approach to development.
While the clicks not code method is a great method available for those less inclined to programming languages, that doesn’t mean you don’t have to be prepared to implement development-like methodologies.
In 2018 Salesforce released the Lightning Flow Builder tool, which is an updated version of their previous Flow tool. It has been overhauled to make it easier than ever to create process-oriented logic that can execute based on actions and events. It’s powerful enough to achieve a lot of the same things that a developer would achieve writing apex triggers. This is all done without writing any code, and adding everything with a point or click using pre-built functions in the Flow designer that are drag and drop.
Understand the Impact
Before taking any action, assessing the task at a high level should be the first step. You’ve been given a design and have been asked to build it, before putting on your gloves and hard hat, it’s better to decide what tools you need to bring with you to the worksite first.
These are typically questions you would ask in any Salesforce configuration or implementation, however there are additional questions that a developer needs to think about when writing custom code. While you are not writing code yourself, you need to approach the tasks as a developer would.
Build a Development Path
While building something within process builder is quite simple, it is because process builder cannot achieve the same complexity as Flow can. Flow can use complex variables, build lists and maps, and loop through sets to determine which decision tree to follow. All of these actions are terms a developer is familiar with.
In order to achieve the same level of work in Flow, it is good to have a general understanding of how a developer works in Salesforce and the best practices when it comes to design and process. In a complex Flow, just like in development, using standard naming conventions for your variables to stay organized will save you a headache when maintaining a very large process. It also makes it easier for others to look at your work and understand if you keep it organized and detailed.
Stay Organized
Staying organized is imperative. Just as a developer would comment out notes and details to explain what things do, be sure to add descriptions to your Flow elements. When you have 100 or more items in your Flow, it may be hard to keep up with everything or come back to something 3 weeks later and remember what it was used for.
It’s also important to keep everything nice and tidy visually. As a developer would nicely format his code by using proper indentation, a Flow needs to be laid out in a way that makes sense and is close to the order of operation it is running in. One of the great benefits of Flow is that it is easily digestible visually when properly formatted.
Pros & Cons
While Flow’s and other “Clicks Not Code” methods can cover a lot of ground that developers would normally cover in Salesforce, there are some limitations. But there are also some benefits. Each scenario should be evaluated to determine the best approach. Follow up with an expansion of this topic in an upcoming blog, where we will dive into evaluating when to use Declarative vs. Conventional Programming in Salesforce.
Looking for more on Salesforce?
Explore more insights and expertise at smartbridge.com/salesforce
There’s more to explore at Smartbridge.com!
Sign up to be notified when we publish articles, news, videos and more!
Other ways to
follow us:
