Apex triggers run business logic when Salesforce records change. That makes them powerful, but it also makes poor trigger design dangerous: one transaction can involve one record, two hundred records, or a chain of related updates created by automation. The current Salesforce Platform Developer<\/a> credential expects developers to understand how programmatic logic behaves on the multitenant platform, not merely how to make a trigger compile.<\/p>\n Bulk-safe design is the practical discipline that keeps trigger logic correct as transaction size grows. It also connects directly to governor limits, testing, security, and deployment. The broader Salesforce certifications<\/a> ecosystem makes the same point from different roles: custom code should complement declarative configuration rather than create a second, opaque platform inside Salesforce.<\/p>\n Trigger design should begin with a short transaction statement: which record event occurs, what related data is required, and what durable result must be true when the transaction completes? That framing prevents trigger code from becoming a collection of unrelated side effects added over time. If several requirements share the same event, handlers can keep them separate while the trigger coordinates execution.<\/p>\n A trigger can run before or after insert, update, delete, and undelete operations. Developers should design around the record event and transaction rather than the UI action that happened to cause it. Data Loader, APIs, Flow, integrations, and user edits can all invoke the same trigger path.<\/p>\n Use the trigger context to understand which records are new, which values existed before, and what operation is taking place. Code that assumes a single record or a specific interface will eventually fail when another entry path sends a larger batch.<\/p>\n Collections are also the foundation for relationship-aware logic. A Set removes duplicate IDs, a Map provides constant-time access to related records, and Lists collect records for DML. These structures let code process a batch as one problem instead of repeating the same problem for each record. Bulkification is therefore an algorithmic design choice, not only a Salesforce coding convention.<\/p>\n The core bulk pattern is simple: treat Trigger.new and related context variables as collections. Accumulate identifiers in Sets, query related records once, store them in Maps, calculate results in memory, and perform DML on Lists. Avoid SOQL and DML inside loops.<\/p>\n This pattern reduces database round trips and keeps the code inside per-transaction limits. The same engineering principle behind scalability<\/a> applies here: design for the shape of real workloads rather than the smallest demo case.<\/p>\n A handler pattern can make feature flags and recursion controls more manageable. Teams can isolate logic into methods such as beforeInsert or afterUpdate and call only the functions relevant to the context. It also makes unit tests easier because business logic can often be exercised through a service class rather than only through implicit trigger execution.<\/p>\n Multiple triggers on the same object can execute in an order that is difficult to manage. Many teams therefore use one trigger per object and delegate business logic to handler classes or domain services. The trigger stays thin while reusable methods hold the actual logic.<\/p>\n This structure is not a platform requirement, but it improves testability and maintainability. It also gives teams a single place to coordinate before and after behavior, recursion controls, and dependencies between rules.<\/p>\n Selective querying includes avoiding unnecessary fields. A query that retrieves ten large text fields when the logic needs only an ID and status uses more heap and may increase serialization cost. Design the data contract for each handler. If a later calculation needs more information, expand the query deliberately rather than defaulting to SELECT-like broad retrieval patterns.<\/p>\n Bulk-safe code does not mean \u201cone query no matter what.\u201d It means querying only the data required for the current batch. Use Sets of IDs or business keys gathered from the trigger records, query matching records once, and map the results back to the affected records.<\/p>\n Large, unfiltered queries waste rows and CPU time. Queries should also respect sharing and field-access expectations in the surrounding architecture. Programmatic access should not accidentally expose data merely because Apex can execute with elevated context.<\/p>\n Partial success with Database methods can be useful for integration or batch scenarios, but it changes error-handling requirements. The code must inspect SaveResult entries, record which rows failed, and decide whether successful records should remain committed. For an interactive business transaction, all-or-none behavior may be safer because the user expects one coherent outcome.<\/p>\n Collect records that need changes, then insert, update, or delete them as a group. Decide whether the transaction should be all-or-none or whether partial success is appropriate for a particular operation. For user-facing validation, addError can block invalid records with a useful explanation.<\/p>\n Developers should also be cautious about trigger logic that updates the same object and re-enters itself. Recursion guards are sometimes necessary, but the better first question is whether the logic can be reorganized to avoid self-triggering work.<\/p>\n Order-of-execution interactions are easier to manage when the team documents which layer owns a field. If a before-save Flow and a trigger both calculate the same status, small configuration changes can create loops or conflicting values. Decide whether declarative or programmatic automation is authoritative, and remove redundant logic instead of adding guards around both.<\/p>\n Salesforce orgs often contain record-triggered Flows, validation rules, assignment rules, rollups, managed-package automation, and Apex. A trigger that appears correct in isolation can cause repeated updates or unexpected ordering when combined with those components.<\/p>\n Before adding code, understand what already happens during the transaction. The administrator perspective in Salesforce Platform Administrator<\/a> is valuable because many requirements can be handled declaratively with clearer ownership and lower maintenance cost.<\/p>\n Limits also influence service boundaries. A helper method called from a trigger should not behave as if it owns a fresh transaction; all code in the synchronous transaction shares the same governor budget. Libraries should therefore accept collections and avoid hidden queries. A reusable method that issues a query every time it is called can defeat bulkification at a higher level.<\/p>\n Apex runs in a shared multitenant environment, so Salesforce enforces limits on queries, DML, CPU time, heap, callouts, and other resources. Exceeding certain limits throws an exception that cannot simply be ignored. Bulkification is therefore not an optional optimization; it is part of correctness.<\/p>\nTriggers respond to record events, not individual button clicks<\/h3>\n
Bulkification starts with collections<\/h3>\n
One trigger per object makes execution easier to reason about<\/h3>\n
Queries should be selective and transaction-aware<\/h3>\n
DML should be grouped and failures should be deliberate<\/h3>\n
Trigger logic has to coexist with declarative automation<\/h3>\n
Governor limits shape the architecture<\/h3>\n