sf-trigger-constraints

Trigger Constraints

When to Use

This skill auto-activates when writing, reviewing, or modifying any Apex trigger or trigger handler. It enforces one-trigger-per-object, handler delegation, bulkification, and recursion prevention rules for all trigger artifacts.

Hard rules that every Apex trigger and trigger handler must satisfy. Violations are blockers -- flag them before any other review feedback.

Reference: @../_reference/TRIGGER_PATTERNS.md (order of execution, context variables, framework comparison).

---

Never Rules

These are absolute prohibitions. Any occurrence is a defect.

ID	Rule	Why
N1	No logic in the trigger body	Trigger files contain only the handler invocation (new Handler().run() or fflib_SObjectDomain.triggerHandler(Domain.class)). Zero conditionals, zero loops, zero DML.
N2	No multiple triggers per object	Multiple triggers on the same sObject have no guaranteed execution order (see @../_reference/TRIGGER_PATTERNS.md, Step 5/9). Consolidate into one trigger file per object.
N3	No DML inside loops	insert/update/delete/upsert/Database.* calls inside for loops hit governor limits. Collect records first, DML once outside the loop.
N4	No SOQL inside loops	Queries inside for loops risk the per-transaction SOQL limit (see @../_reference/GOVERNOR_LIMITS.md). Query before the loop, store results in a Map<Id, SObject>.
N5	No hardcoded IDs	Record IDs, profile IDs, or record-type IDs must never appear as string literals. Use Schema.SObjectType.*.getRecordTypeInfosByDeveloperName(), Custom Metadata, or Custom Labels.
N6	No direct callouts	Apex triggers cannot make HTTP callouts synchronously. Use @future(callout=true) or Queueable with Database.AllowsCallouts.
N7	No Trigger.new modification in after triggers	Trigger.new is read-only in after contexts. Field updates in after triggers must go through a separate DML statement on queried/cloned records.

---

Always Rules

Every trigger implementation must include these elements.

ID	Rule	How
A1	Delegate to a handler class	Trigger body calls handler: new AccountTriggerHandler().run();. All logic lives in the handler or in service classes the handler calls.
A2	Bulkify all logic	Every method must handle List<SObject> (up to 200 records per chunk). No assumption of single-record input. Iterate Trigger.new / Trigger.old, never index [0] alone.
A3	Use a recursion guard	Prevent infinite re-entry. Recommended: static Set<Id> of processed IDs (allows workflow re-fire for unprocessed records while blocking true recursion). Alternatives: depth counter in base class, setMaxLoopCount(). See @../_reference/TRIGGER_PATTERNS.md recursion patterns.
A4	Use Trigger.newMap / Trigger.oldMap for comparisons	When detecting field changes in update triggers, compare Trigger.newMap.get(id).Field__c against Trigger.oldMap.get(id).Field__c. Never rely on list index alignment.
A5	Register all events in one trigger	The single trigger file should subscribe to all seven events (before insert, before update, before delete, after insert, after update, after delete, after undelete) even if the handler only overrides a subset today. This prevents needing a trigger file redeploy when new events are handled later.
A6	Include a bypass mechanism	Support disabling the handler without a code deploy. Use TriggerHandler.bypass() / .clearBypass(), Custom Metadata (Trigger_Setting__mdt), or Hierarchy Custom Settings. Always reset bypass state in a finally block.
A7	Keep handler methods focused	Each onBeforeInsert(), onAfterUpdate(), etc. should call named service methods. If a handler method exceeds ~30 lines, extract to a service class.

---

Anti-Pattern Table

Anti-Pattern	Example	Correct Alternative
Logic in trigger body	trigger T on Account (before insert) { for (Account a : Trigger.new) { a.Name = 'X'; } }	trigger T on Account (...) { new AccountTriggerHandler().run(); } with logic in handler
Two triggers on same object	AccountTrigger.trigger + AccountOwnerTrigger.trigger	Single AccountTrigger.trigger delegating to one handler
DML in loop	for (Account a : accts) { update a; }	update accts; outside loop
SOQL in loop	for (Account a : accts) { Contact c = [SELECT ...]; }	Map<Id, Contact> cMap = new Map<Id, Contact>([SELECT ...]); // before loop
Hardcoded ID	if (acc.RecordTypeId == '012000000000001')	Schema.SObjectType.Account.getRecordTypeInfosByDeveloperName().get('Customer').getRecordTypeId()
No recursion guard	After-update handler updates same records with no static check	private static Set<Id> processedIds = new Set<Id>(); -- skip IDs already in set
Boolean recursion flag	static Boolean hasRun = false; if (hasRun) return;	Set<Id> -- boolean flag blocks legitimate workflow re-fire for unprocessed records
Modifying Trigger.new in after context	for (Account a : Trigger.new) { a.Status__c = 'Done'; } in onAfterInsert	Query records, update separately: update [SELECT Id FROM Account WHERE Id IN :newMap.keySet()]

---

Quick Checklist

Use when writing or reviewing a trigger PR:

• Exactly one .trigger file per sObject
• Trigger body is a single handler call (no logic)
• Handler extends TriggerHandler (or FFLIB fflib_SObjectDomain)
• All seven events registered in trigger definition
• Every loop processes List<SObject>, not a single record
• Zero SOQL or DML inside any loop
• No hardcoded IDs anywhere
• Recursion guard present (prefer Set<Id> pattern)
• Bypass mechanism available
• No Trigger.new mutation in after-trigger methods
• No synchronous callouts

---

Related

• Skill: sf-trigger-frameworks -- Framework patterns, base class code, migration guide
• Reference: @../_reference/TRIGGER_PATTERNS.md -- Order of execution, context variables, framework comparison
• Agent: sf-architect -- Interactive trigger design guidance