I’m not a natural coder, yet ironically it’s followed me around in one way or another over the past 20 years. Having dabbled with a bit of BASIC in my early teens, I was given a Pascal assignment at college. After that I was moved onto C, JAVA and PHP at university before briefly visiting .NET in 2008.

While I’m usually OK at reading and tweaking someone’s code (as long as it’s laid out sensibly), I generally need a spring board to write something from scratch. Because of that, I was happy to leave programming behind when I became a project manager in 2009. From that point, a Gantt chart was to be the most complicated part of the job.

Fast forward 7 years and we’re at the point where I first discover Salesforce. Given my history, I was absolutely on board with the philosophy of Clicks Not Code. That ideology does come with a bit of a caveat though. The mechanisms that drive the declarative configurations in Salesforce have their limits. Limits that can be overcome with a bit (sometimes a lot) of APEX. That does run a risk though and when I read a Tweet by Rob Cowell, it got me thinking.

The sign of a good Salesforce Developer is how much code they don’t write… #clicksnotcode

— Rob Cowell (@RobSalesforce) January 4, 2018

When you know how to achieve exactly what you need with code, in many cases, it can be just as quick to whip something up in a Lightning component/APEX than to use the declarative options. Additionally, the coded version will follow your requirements to the letter, whereas if you use stock functionality, you sometimes (certainly not always) have to bend your needs to fit. Chances are, a declarative option will get you 80% of the way. If you have the skills and time, you can probably get your solution closer to 100%. But should you?

I personally think no, you should not.

There’s a lot of effort that goes in to building a solution in Salesforce. Getting the data model right, designing the page layouts, integrating systems and so on. Building the deliverable to a point where everything is singing and dancing is vital, but it’s just as important to ensure the back end is manageable after you go live.

The beauty of a malleable platform is that it can move and grow with a business. Fields, Objects, email templates and such can easily expand without too much worry, but any automation and business logic needs to be carefully planned. Hard coding picklist values in an APEX class, for example, may limit the options if a business needed to change its processes – this could even be crippling if dealing with managed code that can’t be edited (a problem I’ve encountered). Living with complex code also means you need more skilled personnel to hand.

However, constructing automation solutions using Workflow, Process Builder and Visual Workflow reduces the complexity for maintenance. With code, there are any number of ways to achieve the same result. If you want to update a field using Workflow on the other hand, you’re pretty much going to follow the same steps time after time. Because of that, the back end becomes much easier to look after. You can open up a Workflow and quickly read through the business logic. With code, probably having to follow someone’s work.

If they’re kind, there’ll be lots of //comments.

If they’re sloppy, you can probably just about follow the logic.

If they’re very very clever, they’re most likely using some efficiency tricks that you can’t even begin to break down. And then you break down. And then you cry.

That 80% you can achieve with declarative “clicks not code” may well be good enough in most cases. But for the remaining 20%, I strongly believe you should write just enough code to cover that missing part, and lean on the features you can use without opening up developer console.

It can be too easy to create an efficient and feature rich product with code. But it’s only efficient as long as it meets the business’ needs and when the system requires a tweak here and there, flexibility trumps efficiency.