Welcome to our constantly changing world of CRM, and technology news, expert articles, updates, reviews & opinions.

The Salesforce Dilemma: Declarative Vs Programmatic?


automation image 2

One of the main challenges for Salesforce professionals while implementing Salesforce is the choice of automation strategy and tactics.  Salesforce provides great automation tools for non-developer consultants (like myself) such as workflows, process and visual flows, but when not used carefully, these friendly and visually attractive assistants can become your worst nightmare.As new requirements are being added to the project, that automated flow you created at the very beginning of the project— which made you look smart in front of your colleagues — can suddenly start multiplying like wet gremlins if you’re not careful. The new project requirements result in your automation tactic becoming out-of-control to the point that you may find yourself stuck and needing to call another superhero (since you are not one anymore): your developer.

You see, developers are often involved too late in the automation strategy. This is because we think that we can address most of the project’s requirements using the tools Salesforce provides everyone with, without any programming experience (hey, good logic and common sense is still required. Ok?).

When I started working with Salesforce I quickly got addicted to workflows (limited options but powerful enough for the newbie) but my new fix now is process flows, built using Process Builder: it lets me automate more things with it (create and update related records, send emails, fire an approval process, etc.), control the order of criteria and it is visually sexier and more presentable than its ugly cousin workflow. Salesforce calls process flows “the future of automation” which is correct, up to a certain point, in my opinion.

Regardless of the automation tool you are using — workflow or Process Builder — they will always be lacking the advantages of automation through Apex, which is the Salesforce programming language (and not some planet from the latest Stars Wars movie). The issues are:

  • As new requirements arise, processes are often added to the existing ones without considering the need for process consolidation. There can be many processes executing as a result of a single operation and there is a high risk of losing control of the execution flow. This worsens if triggers are fired as a result of the process executions.
  • Sometimes processes conflict with existing triggers. By definition non-developer consultants are not aware of it since they don't know about the existing triggers.
  • Process flows cannot handle before DML (insert, update, delete) statements. The actions only execute after a record has been created or updated which means an additional update operation is often needed to save the results of the process execution. On the contrary Apex, triggers can handle both before and after DML operations.
  • Process flows cannot handle delete and undelete DML statements whereas Apex triggers can handle all DML operations.
  • An error reported in a process flow is more generic, which makes it difficult to find the origin of the error. With Apex triggers, exception handling can be made more specific, and debugging/testing facilities ease the error tracking.
  • Salesforce still does not enforce testing flows built using Process Builders, which makes it easy to let buggy process flows find their way into your production environment. Apex triggers cannot be deployed to production without being tested first. This does not mean that there is no buggy Apex code of course, but it certainly increases the level of confidence you can have in your automation solution.
  • It is all or none in case of process flow failure, but with Apex triggers, partial success is possible.
  • Last but not least, process flows in the end can be seen as hidden coding made simple thanks to the use of a graphical representation. Therefore, they are programmed to execute the “nominal” case only, and potential exception scenarios — that would look obvious to a developer — are often omitted.
If you are not on the tech side of Salesforce, what I just mentioned might sound like the type of thing that people from the remote planet of Apex may say. My point is, that even though Salesforce is one of the greatest point-and-click solutions on planet Earth, there will always be a time when development will have to be included in your automation strategy.

My advice is this: use Salesforce automation tools at the beginning of your project or when you need to automate a simple and straightforward operation. However, if you need to automate a complex process or realize that you have too many exceptions to address in your automation, go and seek development expertise, which your Salesforce partner is able to provide you with (hey, stop looking at me!).

In the end, automating your process in Salesforce is like everything else in life, a matter or balance… and moderation!

For more info, please contact us via email on This email address is being protected from spambots. You need JavaScript enabled to view it. and we would be happy to chat with you.

Lightning switch: do’s and don’ts for a successful...
CRM for Startups - Too early to be good?

By accepting you will be accessing a service provided by a third-party external to

Subscribe to our Newsletter

You will receive regular information about our events, expert articles, the latest success stories, news about our NexellAngels initiative and much more.