Avoid common Apex trigger pitfalls with Apex Trigger Best Practices and a Salesforce Trigger Framework for clean, scalable code.
Coding Triggers Right the First Time
Apex triggers are the backbone of automation in Salesforce. Yet even experienced developers fall into common traps—leading to poor performance, broken deployments, and unmaintainable code. While the excitement of writing custom logic is real, skipping the foundations of Apex Trigger best practices or neglecting a Salesforce Trigger framework can sabotage your CRM’s stability.
This blog thoroughly explores the top mistakes developers often make in Salesforce Apex triggers. Moreover, it compares best-in-class techniques; in addition, it offers practical guidance to help you write scalable, reusable, and, most importantly, future-proof code. As a result, you’ll gain not only cleaner logic but also better long-term performance across your Salesforce org.
1. Choosing Apex Triggers Over Flows Without Justification
Many developers instinctively reach for Apex triggers—even when a Record-Triggered Flow would do the job just as well, if not better.
Why It’s a Mistake
- Low-code first is the Salesforce principle.
- Triggers require test classes, flows do not.
- Admins can’t update triggers but can handle Flows easily.
Best Practice
Before writing code, evaluate if the logic can be achieved declaratively. Using Apex where Flow suffices violates modern Apex Trigger best practices, increases technical debt, and reduces agility.
2. Ignoring the Salesforce Trigger Framework
A standalone trigger with mixed logic might work—until it doesn’t.
Symptoms of Poor Design
- Business logic directly inside triggers
- Duplicate DML or SOQL operations
- Recursion nightmares
- Unit testing becomes painful
Framework vs No Framework
| Feature | Without Framework | With Salesforce Trigger Framework |
| Logic Separation | ❌ All-in-one clutter | ✅ Handled in trigger handler classes |
| Reusability | ❌ Low | ✅ High |
| Recursion Handling | ❌ Prone to infinite loops | ✅ Controlled via static variables |
| Scalability | ❌ Limited | ✅ Modular and extensible |
Best Practice
Always implement a Salesforce Trigger framework to separate business logic, streamline testing, and simplify maintenance.
3. Failing to Bulkify Triggers
One of the most frequent—and fatal—offenses is writing logic that assumes single-record context.
apex
// DML inside loop – DON’T DO THIS
for (Account acc : Trigger.new) {
update acc;
}Why It’s Dangerous
- Violates governor limits (especially SOQL/DML limits)
- Causes runtime exceptions in bulk operations
- Crashes during Data Loader imports or integrations
Best Practice
Follow Apex Trigger best practices by extracting SOQL and DML outside of loops. Use collections like Set<Id> and maps to handle bulk operations efficiently.
4. Overlooking Trigger Execution Context
Not using Trigger.isInsert, Trigger.isUpdate, or Trigger.isBefore properly? You’re gambling with data logic.
Problem
Logic might run in unintended contexts, leading to:
- Double updates
- Missed automation
- Conflicting outcomes
Best Practice
Use execution context flags precisely to ensure logic runs only in its intended phase. It’s a core component of the Salesforce Trigger framework approach.
5. Not Controlling Recursion
Recursion errors can silently ruin data or completely crash processes.
Bad Example
apex
trigger AccountTrigger on Account (after insert) {
update Trigger.new;
}Best Practice
Use a static Boolean flag within your handler class:
apex
public static Boolean hasRun = false;Control recursive runs elegantly within the Salesforce Trigger framework. This is a gold standard of Apex Trigger best practices.
6. Hardcoding IDs or Picklist Values
Many developers hardcode record type IDs or user IDs during development—only to find everything breaks in another sandbox or production.
Why It Fails
- RecordTypeIds are org-specific
- Makes deployment error-prone
- Leads to inconsistent logic and failed tests
Best Practice
Always query record types or reference values dynamically using Schema. Avoid hardcoding—it’s an anti-pattern that defies all Apex Trigger best practices.
7. Skipping Proper Error Handling
Uncaught exceptions, if not handled properly, can silently crash triggers. As a result, users may encounter vague errors; furthermore, this can lead to inconsistent data across the system. Therefore, it’s crucial to implement proper exception handling to ensure reliability and maintain data integrity.
What to Do
Use structured try-catch blocks. Add meaningful addError() messages to provide user-friendly feedback.
apex
try {
update accounts;
} catch (DmlException e) {
for (Account acc : Trigger.new) {
acc.addError('Failed to update: ' + e.getMessage());
}
}This aligns with robust Salesforce Trigger framework implementation patterns.
8. Writing Multiple Triggers on One Object
Salesforce does not guarantee trigger execution order. So if you have two triggers updating the same field—whichever runs last wins. It’s a risky game.
Best Practice
Adopt a one trigger per object strategy and manage all logic via handler classes. This is non-negotiable in Apex Trigger best practices.
9. Neglecting Unit Tests or Writing Poor Coverage
Low code coverage, in addition to untested edge cases and missing assertions, are all clear signs of poor trigger hygiene. Moreover, these gaps not only reduce deployment success but also increase the risk of bugs in production. Therefore, consistently writing thorough tests is essential; similarly, including edge cases and strong assertions helps ensure long-term stability.
Best Practice
- Target >90% coverage
- Cover all trigger contexts
- Use real-world scenarios and edge cases
- Test bulk operations
Framework-based triggers make writing tests far easier and cleaner.
10. Ignoring Naming Conventions
Trigger names like tr1 or trigger_123 destroy readability.
Best Practice
Follow standard naming like:
apex
trigger AccountTrigger on Account (before insert, after update) { }This ensures clarity and consistency for your dev team.
Clean Code Is Smart Code
Apex triggers, without a doubt, can make or break your Salesforce org. To illustrate this, the blog highlights key mistakes developers often make—for example, skipping bulkification, hardcoding values, or ignoring recursion. Furthermore, it not only explains why these issues matter but also outlines practical solutions to help you avoid them. As a result, you’ll be better equipped to write efficient, stable, and future-ready trigger logic. By following Apex Trigger Best Practices and using a solid Salesforce Trigger Framework, you can write cleaner, scalable, and more reliable trigger code that’s ready for the real world.
FAQs
1. Why should I use a Salesforce Trigger framework?
It promotes separation of concerns, simplifies unit testing, prevents recursion, and ensures code reusability across objects.
2. What is the biggest mistake developers make in Apex triggers?
Failing to bulkify logic—this causes runtime exceptions and violates governor limits.
3. Can I use both Flow and Apex together?
Yes, but use Apex only where Flow falls short. Salesforce recommends a low-code-first approach.
4. How do I prevent recursive triggers?
Use static variables in your handler class to ensure the logic runs only once per transaction.
5. Are multiple triggers allowed on the same object?
Yes, but it’s strongly discouraged. It can cause unpredictable results. Always use one trigger per object.
Feeling more like puzzles than solutions? That’s when Sababa steps in.
At Sababa Technologies, we’re not just consultants, we’re your tech-savvy sidekicks. Whether you’re wrestling with CRM chaos, dreaming of seamless automations, or just need a friendly expert to point you in the right direction… we’ve got your back.
Let’s turn your moments into “Aha, that’s genius!”
Chat with our team or shoot us a note at support@sababatechnologies.com. No robots, no jargon, No sales pitches —just real humans, smart solutions and high-fives.
P.S. First coffee’s on us if you mention this blog post!
