Apex vs. Declarative

Salesforce has increased their effort to create new and improved declarative tools for customization. Their mantra has been “Clicks not Code” from the beginning and they have certainly delivered on that over the years. With each new release (3x a year!) it is easier for an end user to create complex automations based on these declarative tools, such as Flows and Process Builder, which have an intuitive and powerful user interface.

On the other hand, Salesforce provides programmatic customization, that means, developing software based on their own language called “Apex”. Both ways of customization have pros and cons, and given our experience we want to share our lessons learned. And we have definitely learned some lessons.

Declarative customization goes from simple things as custom objects, custom fields, formulas to more complex tools as process builders, flows, workflow rules, approval processes and others components to help your business processes be more efficient. The good news is that a non-technical person can create amazing automations with “just” a click and point tool, obviously you still need to have knowledge about some topics as object model, data fields, processes and have a clear idea about the goal with the customization. The not so good news is that a non-technical person may not know the Salesforce limits, and this is one of the most important things for an optimized solution.

Programmatic customization involves components as Apex Classes, Apex Triggers, schedule jobs, batch processes, integration with other platforms and a big world of options, all the things that you can create using declarative tools are able to be built using programmatic tools but not the opposite. The person who creates programmatic solutions needs more technical knowledge and a deep understanding of the platform architecture, limitations and algorithms. I dare to say that “every” need is possible to solve it through a programmatic solution.

Some of the cons of doing programmatic customizations are that they are commonly time-consuming for building, you need a software developer and you can not create it directly in production instances. Opposite of declarative solution, good point for declarative tools!

Some of the cons of doing declarative customizations are that in some cases you can not perform complex operations, you can not control the order of execution and you can easily fall into recursion or call multiple times the same function, causing errors on the execution that are tough to identify. That last point is one of the major pain points we have found in some salesforce implementations and it’s the objective of this writing.

Here are some of our recommendations when you are building declarative solutions:

• Centralize the design and building of these components in an Admin person/team, if there are a disparate group of people creating solutions, one person does not have the big picture or does not know what other admins are doing, and may create duplicates or generate conflict with the solution.
• As it looks like declarative tools are easy to create, the user can be tempted to create many automations for each simple need instead of grouping the simple needs and design/build a reduced number of automations that can meet all the needs.
• Pay attention to nested calls, you can create declarative customization thinking that they are going to run isolated but that could not be the expected result, keep in mind the architecture of the platform and how everything is working together.