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.
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.
But,While writing any trigger in Salesforce , we need to keep some point in mind in order to make it work perfectly in bulky scenarios too. Below are the precautions that any dev or admin should keep in mind while writing trigger :
- One Trigger Per Object
A single Apex Trigger is all you need for one particular object. If you develop multiple Triggers for a single object, you have no way of controlling the order of execution if those Triggers can run in the same contexts
- Logic-less Triggers
If you write methods in your Triggers, those can’t be exposed for test purposes. You also can’t expose logic to be re-used anywhere else in your org.
- Context-Specific Handler Methods
Create context-specific handler methods in Trigger handlers
- Bulkify your Code
Bulkifying Apex code refers to the concept of making sure the code properly handles more than one record at a time.
- Avoid SOQL Queries or DML statements inside FOR Loops
An individual Apex request gets a maximum of 100 SOQL queries before exceeding that governor limit. So if this trigger is invoked by a batch of more than 100 Account records, the governor limit will throw a runtime exception
- Using Collections, Streamlining Queries, and Efficient For Loops
It is important to use Apex Collections to efficiently query data and store the data in memory. A combination of using collections and streamlining SOQL queries can substantially help writing efficient Apex code and avoid governor limits
- Querying Large Data Sets
The total number of records that can be returned by SOQL queries in a request is 50,000. If returning a large set of queries causes you to exceed your heap limit, then a SOQL query for loop must be used instead. It can process multiple batches of records through the use of internal calls to query and query More
- Use @future Appropriately
It is critical to write your Apex code to efficiently handle bulk or many records at a time. This is also true for asynchronous Apex methods (those annotated with the @future keyword). The differences between synchronous and asynchronous Apex can be found
- Avoid Hard coding IDs
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages, it is essential to avoid hard coding IDs in the Apex code. By doing so, if the record IDs change between environments, the logic can dynamically identify the proper data to operate against and not fail
We at the Erudite Works focuses on writing a trigger which is fully optimized and work on most bulky scenarios too.