TL;DR: Salesforce limits each transaction to 150 DML statements (INSERT, UPDATE, UPSERT, DELETE). If your automation fires the 151st, Salesforce stops the transaction, rolls everything back, and throws the error:
System.LimitException: Too many DML statements: 151.

*

This guide explains what the error means, why it happens, and how to fix it — including how Sweep helps you detect and prevent DML limit violations before they reach production.

What “Too Many DML Statements” Means in Salesforce

Salesforce protects its multitenant architecture with strict governor limits, and the DML cap is one of the most important. Every DML statement:

• Locks records
• Hits the database
• Consumes CPU
• Can trigger additional automation

When your transaction performs more than 150 DML operations, Salesforce terminates the transaction and reverts all changes.

This is a hard system limit — no retries, no partial commits, no exceptions.

What Counts Toward the DML Limit (and What Doesn’t)

Understanding this distinction is critical for Salesforce admins and architects.

Counts toward the 150 DML statement limit

• INSERT, UPDATE, UPSERT, DELETE, UNDELETE
• Any Flow that performs a record update
• Process Builder field updates
• Workflow field updates
• Apex DML (triggers, classes, handlers)
• Managed packages that run in the same transaction

Does NOT count toward the limit

• Before-Save Flow field assignments
• SOQL queries
• Formula calculations
• Callout wait time
• Asynchronous operations (Queueable, Batch Apex) — these run in separate transactions

Key insight:
You can loop thousands of records without issue — the limit is triggered only when you save records too many times.

Common Causes of “Too Many DML Statements: 151”

1. Updating records one at a time instead of in bulk

This is the #1 cause globally.
1 record = 1 DML.
200 records = 200 DML.
→ Immediate limit violation.

2. Multiple automations updating the same record

A single update may trigger:

• A Flow
• A Process Builder
• A package trigger
• A workflow field update

Each one may perform DML, meaning your “one update” becomes many.

3. Recursive updates (automation loops)

Record A updates Record B → which updates Record A → which updates Record B…

Even small loops blow through DML quickly.

4. Misconfigured After-Save Flows

After-Save Flows always perform implicit DML.
If the work could be done Before-Save, you avoid an entire DML statement.

5. Heavy managed package behavior

Packages often re-save records or maintain internal audit logs.
All of that counts toward your 150 limit.

How to Diagnose DML Limit Errors in Salesforce

Step 1 — Enable and capture debug logs

Set Apex Profiling → FINEST.
Reproduce the error.

Step 2 — Analyze the Timeline in Developer Console

Look for:

• Repeated UPDATE events
• Multiple executions of the same Flow
• Recursion patterns
• Managed package activity

Step 3 — Check namespace usage

Search logs for:

LIMIT_USAGE_FOR_NS

You’ll see which automation (your code or packages) is consuming DML statements.

How to Fix “Too Many DML Statements”

Quick Wins

• Bulkify updates (update collections, not individual records)
• Migrate logic to Before-Save Flows wherever possible
• Consolidate Flows/Triggers to avoid duplicate DML
• Add recursion guards
• Remove redundant “update record” actions
• Use caching techniques to avoid repeated writes

Architectural Fixes

• Offload heavy updates to Queueable or Batch Apex
• Reduce cross-object “ping-pong” updates
• Use platform events for asynchronous, decoupled updates
• Reevaluate unnecessary automation touching the same object

DML Limit Prevention Checklist (Before You Deploy)

Ask yourself:

• Does another Flow or trigger already update this object?
• Does this cause downstream updates I’m not accounting for?
• Could this run Before-Save instead of After?
• Does this risk recursion?
• Am I updating records one-by-one?
• Have I tested with large batches (not just one record)?

When Integrations Trigger DML Limit Errors

If the error originates from an external system:

• Reduce batch size of updates
• Ensure unchanged fields aren’t being resent
• Avoid parallel writes to the same parent record
• Move expensive updates into asynchronous paths
• Inspect whether your integration triggers too many internal Flows

The Takeaway

DML statement limits aren’t arbitrary — they’re a signal your automation architecture is performing unnecessary or repetitive updates.

Fixing this isn’t about squeezing around the limit. It’s about building an org where:

• automation is consolidated
• logic is bulkified
• recursion is prevented
• heavy lifting is moved to async
• dependencies are understood before deployment

Using Sweep? Here’s How to Fix DML Issues Instantly

See how Sweep maps every automation, dependency, and execution chain — so you can identify excessive DML behavior in seconds.
Explore the Automation Map →

Sweep gives teams unmatched visibility into DML-heavy automation patterns:

Find the DML source automatically

Sweep reveals:

• All Flows and triggers firing on save
• Duplicate automations doing redundant updates
• Cross-object update chains
• Hidden managed package logic
• Automation loops that lead to recursion

Prevent DML violations before deploying

Sweep’s Impact Analysis flags:

• Changes that increase DML
• Flows that perform unnecessary “update record” actions
• Triggers that cause cascading downstream updates
• Automation chains that exceed best-practice thresholds

Document automation rules to prevent future sprawl

CPU and DML errors often appear months later, after small, untracked changes stack up. Sweep centralizes automation documentation so teams don’t unknowingly recreate the same problems.