Maximum trigger depth exceeded: how to find the save loop

What the error looks like

The message usually arrives inside a DML error. A typical form is:

CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, AccountTrigger: maximum trigger depth exceeded

The trigger named before the colon is where the limit was reached. It is not always where the loop starts.

Some loops that run through flows report a different message, MAX_DEPTH_IN_FLOW_EXECUTION: Maximum flow depth exceeded (reported in the Trailblazer Community). The cause and the fixes on this page are the same.

Why it happens: Salesforce’s re-run rules

Salesforce counts nested trigger runs. Its Execution Governors and Limits page sets the “total stack depth for any Apex invocation that recursively fires triggers due to insert, update, or delete statements” at 16. The same page explains why: a trigger fired by DML starts a new Apex invocation, which costs more than a normal method call.

So the question is always: what sends the record back through a save? The Triggers and Order of Execution page in the Apex Developer Guide (Winter ‘27, API 68.0) answers it:

Two practical points follow.

• A workflow field update alone re-runs triggers once. The deep loops come from Apex DML or flow DML.
• “My flow runs twice” is usually the second row. An after-save flow or after trigger updates the same record, and your before-save flow runs again in the recursive save.

How to find the loop

1. Reproduce it with a debug log. Set a trace flag on the user, repeat the save, and open the log. Search for the trigger name from the error. Count how many times it starts, and note what ran just before each start.
2. List every automation on the saved object. Include before-save flows, Apex triggers, validation rules, after-save flows, workflow rules and processes. In Setup, Object Manager shows triggers per object and Flow Trigger Explorer shows record-triggered flows.
3. Mark the ones that write back. For each automation, ask one question: does it write to a record of the same object?
   • Apex: look for update, insert or upsert in after-trigger handlers and the classes they call.
   • Flow: look for Update Records or Create Records elements on the same object, including $Record updates in an after-save flow.
   • Workflow: look for field updates.
4. Follow cross-object chains. An Installation update can change a Project, and a Project trigger can update Installations. Neither automation looks recursive on its own.
5. Check for a guard. See whether the trigger or handler keeps track of what it already processed.
6. Check roll-ups. A child save that recalculates a parent roll-up re-saves the parent. If the parent’s automation updates the children, you have a loop.

Fix patterns

With sf-intelligence

sf-intelligence reads your org’s metadata on your own computer. It lists, for an object, every step that writes back to it, plus what Salesforce’s rules say runs again. Here it is on Verdant, the built-in demo org (a fictional solar installer).

Ask: “What happens when I save an Installation, and does anything write back to it?”

"reentry": {
  "writeBacks": [],
  "cascades": [
    { "step": 1, "componentId": "Flow:Installation_On_Complete",
      "object": "Service_Visit__c", "operation": "recordCreate", "targetAutomation": 0 },
    { "step": 1, "componentId": "Flow:Installation_On_Complete",
      "object": "Project__c", "operation": "recordUpdate", "targetAutomation": 2 }
  ]
}

Ask the same about Project and you get the next hop. ProjectTrigger sets Risk_Score__c in its before-update step, which needs no DML. Its after-update step only logs. The Project_On_Approve flow creates a Permit, which has no automation. Again, nothing writes back.

So the Verdant demo has no save loop to find. That is a real result, and each step is cited. One risk remains: the separate code-quality check (code_quality_audit) reports that ProjectTrigger “has no recognizable recursion guard”. In an org with a loop, the answer lists each step that writes to the saved object, the fields it writes, and the quoted Salesforce rule for what runs again.

What it does not see, in its own words: “Conditions are not evaluated. Not listed: approval-process field updates, time-triggered workflow updates, Process Builder processes … DML inside subflows or invocable actions.” Managed-package code is also out of reach. Use the debug log to confirm what fires for a specific record.