Apex Triggers are a powerful tool for automating a range of tasks, from data validation to custom business logic. In this article, we鈥檒l cover some of the fundamentals to be aware of when working with Apex Triggers. Then we鈥檒l explore some of the smart functionality 91导航 has for making Apex deployments easier.
When to use Apex Triggers
Using Apex Triggers, you can specify actions that should happen immediately before or after a record is inserted, updated, deleted, merged, upserted, or even undeleted.
Apex Triggers perform a similar function to Record-Triggered Flows. If the process you need to automate is fairly straightforward and supported by Flows, then a Record-Triggered Flow might be the best option. But Apex Triggers offer you more flexibility, as you can create a more complex automated process with custom code.
For large-scale data processing, Batch Apex may also be an option. But Batch Apex executes on a schedule or on demand, not via triggers. It鈥檚 designed for a smaller number of large processes 鈥� only five Batch Apex jobs can run at the same time. If you need a custom process to happen immediately, every time a certain kind of record changes, you should use Apex Triggers.
TDX
Apex Trigger best practices
There are plenty of pitfalls to avoid when writing Apex Triggers, and various ways to optimize your code. You鈥檒l find helpful guides in Salesforce鈥檚 , as well as from the .
The most important best practices to know are:
- Avoid multiple triggers per object. It鈥檚 possible to create multiple Apex Triggers for one object, but there鈥檚 no quick way to determine the order in which they should run.
- Make sure you have no recursions. Your Apex Triggers shouldn鈥檛 call themselves, either directly or via another Apex class.
- Bulkify your code. Write Apex Triggers that still work when several records change at once.
Another important area to consider is code reuse. It鈥檚 easier and more efficient to maintain a codebase where the same functions use the same code. For example, you might want to write helper classes that can be used by multiple triggers. But you should keep separation of concerns, so that refactoring code doesn鈥檛 unintentionally break something.
Do you need a test class for an Apex Trigger?
While you don鈥檛 strictly need to write a test class to create and deploy any given Apex Trigger, you do need to maintain code coverage of at least 75% 鈥� otherwise you won鈥檛 be able to deploy your code to production.
You should write test classes for Apex Triggers just as for any Apex class. Tests make sure your code executes as intended, and you can automate unit tests in production to avoid silent test failures caused by breaking changes. Test-driven development 鈥� writing robust tests first then creating code that passes those tests 鈥� is a best practice approach.
As well as testing your Apex Triggers, running static code analysis will improve your code quality. With an agreed ruleset across your development team, your codebase will become more consistent, efficient, and secure, as well as being easier to review and refactor.
How to deploy Apex triggers natively in Salesforce
Apex classes can鈥檛 be written in production. They must be created in a development environment and deployed to production.
There are several options for deploying on Salesforce, from native tools to third-party solutions. In the rest of this article, we鈥檒l look at how to deploy using change sets, and how the same deployment works with 91导航.
You can only use change sets to deploy between Salesforce orgs. If you haven鈥檛 already set up a connection between your sandbox and production orgs, you鈥檒l need to connect and authorize deployments between them.
1. Build an outbound change set
In your sandbox org, head to the Outbound Change Sets page and find the components you want to deploy. You鈥檒l need to work out which bits of metadata you鈥檝e changed, and all of their dependencies. For example, if you鈥檝e written a test class for your Apex Trigger, you鈥檒l need to deploy them both. Clicking View/Add dependencies will show you the components your trigger depends on 鈥� these should all be included in your change set.
2. Upload the outbound change set
From the Outbound Change Sets page, click Upload for the change set you want to deploy. Once you鈥檝e uploaded a change set, it can鈥檛 be recalled or edited.
3. Log in to your production org
To deploy the change set, you must log in to the target org 鈥� ultimately this will be the production org. This means anyone involved in deployments to production must have login access to the production environment, which isn鈥檛 ideal from a security viewpoint.
4. Deploy the inbound change set
Head to the Inbound Change Sets page and find the relevant change set with your Apex Trigger. You can validate a change set before deploying. If your validation or deployment fails, you鈥檒l need to work out what went wrong, implement a fix, then try again with another change set from the sandbox org.
Note: Unlike other metadata changes, there is no way to delete Apex in production, and you can鈥檛 deploy deletions via change sets. Another deployment tool will be needed to remove any Apex Triggers from production.
How to deploy Apex Triggers using 91导航
Using 91导航 to deploy Apex Triggers has several advantages over change sets:
- Complete visibility of your the differences between your orgs
- Automatic problem analysis for common errors like missed dependencies
- Automatic detection of relevant tests to run during deployment
- Validations and deployment scheduling ahead of time
- The ability to cherry pick individual lines of code to deploy
- The ability to make destructive changes safely
- Full or partial rollback of any deployment in your 91导航 history
All this makes deployments faster and easier 鈥� and that鈥檚 before even getting on to a mature DevOps process in 91导航 with a CI/CD pipeline for automated deployments.
If you鈥檇 like to follow along with this walkthrough, you can try all of 91导航 free for 30 days.
1. Build your deployment package
First, select the source and target for your deployment. In this example, we鈥檙e deploying from a developer org to production, but you can deploy to and from version control or a scratch org using exactly the same workflow. Unlike with change sets, users can have delegated access to deploy to an org, without having login access to that org.
In this example, we鈥檙e going to use 91导航鈥檚 recently upgraded comparison workflow, so we鈥檒l hit Compare now 2.0.
Apex classes and Apex triggers are included in 91导航鈥檚 鈥渂asic comparison鈥� filter, so selecting that pulls the relevant metadata into our comparison.
We can see all the items of those metadata types listed in the top half of the page, and by selecting an item we can see the exact differences between source and target in the bottom half of the page.
For Apex classes and triggers, you can select specific lines of code to deploy with 91导航鈥檚 Precision Deployments. This allows you to deploy individual methods or code blocks while holding back other changes you鈥檙e still working on, and avoids overwriting work in the target.
91导航 displays the most recent changes at the top, as they鈥檙e most likely to be the changes we want to deploy. So we can see our TestAccountDeletion test class and our AccountDeletion Apex Trigger. We can open up the dropdown for any item and explore its dependencies and related items.
When we鈥檝e selected our items for deployment, we can click Next. In this example, we can see we forgot to select our AccountDeletion trigger 鈥� we鈥檒l see how 91导航 handles that.
2. Act on any problem analysis results
91导航 has dozens of problem analyzers that find and fix common deployment issues. Missing dependencies are a classic example, and here we can see that 91导航 is fixing our mistake from earlier.
We can also look at static code analysis results for the Apex code we鈥檙e deploying. Our team has configured a PMD ruleset and this test class doesn鈥檛 follow our agreed conventions. This won鈥檛 block our deployment right now, although you can change the settings in 91导航 to enforce particular rules and improve code quality.
3. Deploy the package
Pressing Pre-deployment summary takes us to a summary of all the items we鈥檙e going to deploy. We can add a name and notes to the deployment. We can connect the deployment to one or multiple tickets in our work tracking tool, append a list of deployed items to the tickets, and even move tickets along the kanban board.
Clicking the arrow next to Deploy now, we can see options for running unit tests during this deployment. 91导航 can automatically detect the relevant tests to run, based on the tests in our deployment package and any dependencies. You can also choose to schedule the deployment for a later time, such as midnight or a weekend, when it鈥檚 less likely that there will be end users in the target org.
Once we鈥檝e run our tests and deployed the changes, we get a summary of the deployment and can download a full PDF report.
Should we need to, the deployment can be rolled back from our deployment history.
Pull the trigger!
Deploying Apex Triggers can be quick and easy with 91导航鈥檚 Salesforce metadata deployment solution! If you鈥檙e ready to get started with 91导航, sign up for a or arrange a tailored demo to explore the full platform.
