When to code in Salesforce is a topic that comes up a lot. It’s a common interview question for Salesforce developers and Pluralsight even has an entire course on the subject. I have heard many times that we should use declarative whenever possible and code as a last resort. Some teams even quantify it with goals like 90% declarative and 10% code.
Why do so many Salesforce developers have a bias against code? There are several reasons.
History: Salesforce used to push the no-code message hard. Then they backed that up by building a lot of great tools for building automation that don’t require code like Workflows, Process Builder, etc.
Speed: There’s no question that many tasks can be done much faster with clicks than code.
Skill-set: Many Salesforce developers are more comfortable with declarative tools than code.
Risk: Clicks or code can introduce bugs but there are more opportunities for introducing bugs with code.
I mostly agree that we should use declarative when possible and I agree for all of the reasons above. But I don’t always agree. Just like anything else this idea of clicks over code can be taken to an extreme.
I recently saw a custom object with 9 record types and fields that were added to track UI state with names like “Are you sure you want to proceed?” The record types, strange fields plus a few workflows were used to create a UI experience that I would have expected to create with lightning web components or a Visualforce page. It took some time to figure out what it was doing and how. And I admit, I was impressed at first. But it was a hack. The UI worked but felt hacked together and the data model was polluted with fields that didn’t hold meaningful data. The same functionality could have been created with a relatively small amount of code without polluting the data model and with a UI that felt more natural and less hacked together.
In the .Net and Java worlds you hear people talk of code smell. It’s code that has such a poor structure, organization or is so clearly a hack that it has a bad smell. Recognizing code smell is a sense that is developed with time and experience. As Salesforce developers I think we also need to develop our sense of smell. Not just for code but for declarative work that is poorly structured, organized or is clearly a hack. That allows us to go beyond simple rules like “clicks over code” and choose the option that will be best for our users and for the long-term maintainability of our projects.