If you’re a regular reader of this blog, you probably already know that there are multiple ways to automate processes in Salesforce. You probably also know that you don’t need to to have a coding background to start automating processes. With Workflow Rules, Flows, and Process Builder at your fingertips, you might even feel like code isn’t necessary. There are, however, some good reasons to prefer code over clicks in some circumstances. In this post we’ll look at automating processes with code, specifically with Apex Triggers. We’ll look at the benefits of automating with Triggers and the situations where you would want to use them over no-code automation options.
Reasons Not To Use Triggers
But first, let’s talk about the reasons why we don’t use Triggers. I know I said that we were going to be looking at the benefits of using Triggers, but it will help if we have the usual objections to using Triggers in mind while we review those benefits. The main reason that users will avoid Triggers is that they don’t know how to write code or don’t have the budget to pay a developer to build a Trigger. These reasons are hard to argue with. If no-code options are your only options, then you have to go with them. On the flip side, you will encounter circumstances where only code will accomplish what you want. In these cases, you’ll want to use Apex Triggers as the more powerful option.
Another reason for using no-code options is that, for simple automation, they are easier and faster to create and deploy. When you build a new Trigger, you’ve got to create a new Sandbox and write tests for your Trigger. You’ve got to run your tests until they pass and debug your code when they fail. And when you’ve finally got everything right, you still need to deploy to production. If all you need to do is send an email when a record meets specific criteria, then use a Workflow Rule. You’ll have it working in fifteen minutes. For more complex automation, you might find that this ease of deployment comes with a catch. We’ll look more at that later in the post.
Triggers are Powerful
Now we turn to the benefits of Triggers. The first is one that I’ve mentioned already. They are simply more powerful than non-code automation options. Workflow Rules and Processes can only run in two situations, after a record is created or after it’s updated. Triggers can fire before or after creating, updating, or deleting records. They can also fire after undeleting records. Workflow rules don’t allow for branching logic and can only perform five different actions, and a couple of them only in a limited way. Process Builder allows a few more actions, and some very simple logic. But Triggers are only limited by what you can do in Apex. They allow for loops and complex logic and allow you to take almost any action that Salesforce is capable of taking.
Triggers are Faster
Flows in Salesforce are capable of performing actions nearly as complex as those that can be done by Triggers. And while Flows may be capable enough for any automation you might need, there are reasons for avoiding overly complicated Flows. First, Flows will execute more slowly and use more CPU time than Apex Triggers performing the same task. If you bulk-create or bulk-update records that will launch a complex Flow, you may even get an error that the Apex CPU time limit was exceeded. A well written Apex Trigger would resolve this problem.
Writing Tests Actually Saves Time
Complex Flows can also be difficult to test. It’s important to test them thoroughly, even though Salesforce doesn’t require it. If you want to test a Flow launched by a Process, you need to activate the Flow and update or create data in your Sandbox. You’ll need to bulk create records using a data loading tool to see how the Flow responds when it needs to be run for 200 records. With an Apex Trigger, you write all of your tests with code and, if you need to make changes to your Trigger to address bugs, you can rerun your tests with the click of a button.
Remember when I said that the ease of deploying non-code automation comes with a catch? Salesforce requires you to write tests for a reason. Let’s say you are deploying some new code to your Production Salesforce instance and that new code breaks an existing Flow. You may not even know about the issue until you get an email with an error message in it. Then you have to debug you Flow on a live Production instance. For simple Flows or Workflow Rules, this probably isn’t a big deal. But complex Flows could cause some difficulty. The tests that you write for a Trigger insure that no additional code can deployed unless those tests pass. It allows you to discover and troubleshoot issues in your Sandbox, where bugs are easier to deal with.
When To Use Triggers
This is not to say that you should stop using Flows entirely. As I said in the beginning, Workflow Rules, Process Builder, and Flows are great. Take advantage of them as much as you can. You will run into situations, though, when these options fall short. If you’ve investigated no-code options and they just can’t do what you need them to do, check out Triggers. If you’re working on a Flow that feels like it’s getting out of hand, consider using a Trigger instead.
For additional reading:
