Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
All errors
Integration

EXCEEDED_ID_LIMIT: record limit reached

You hit one of Salesforce's hard caps on a record-related operation: too many sharing rows on one record, too many child records on one parent in a master-detail, too many junction-object rows. The fix depends on which cap, but the error always names the offending sObject.

Also seen asEXCEEDED_ID_LIMIT·record limit reached·EXCEEDED_ID_LIMIT: record limit

"EXCEEDED_ID_LIMIT" is one of those error codes that bundles several distinct caps under one name. The error message extension tells you which.

The most common variants

1. Too many child records under one parent

Master-detail relationships: a single parent record can have at most 10,000 child records in the master-detail. Hit 10,001 and the next insert fails. The fix is either re-architecting the relationship or breaking the parent into multiple "logical" parents.

In practice this usually shows up on:

  • Opportunity → OpportunityLineItem with massive line-item counts (rare, but seen on quotes)
  • Custom master-details where a "container" record accumulates children over time

2. Sharing-row cap

A single record can have at most 5,000 sharing rows (manual + Apex managed + calculated). When a record gets that popular — often a public Account in a tightly-shared org — additional sharing fails.

Diagnose:

SELECT COUNT(Id) FROM AccountShare WHERE ParentId = '0016xxxxxxxx'

Fixes:

  • Use Public Groups instead of individual user shares (one group share covers many users)
  • Restructure ownership so role-hierarchy access does the work
  • Use Apex managed sharing with a stable row set (delete + re-create when membership changes) instead of accumulating

3. Asynchronous job queue cap

You can't have more than 50 jobs queued in a future-and-batch combined queue per org. A spike of @future calls (or a runaway loop kicking off jobs) hits this cap quickly.

Diagnose:

SELECT Id, JobType, Status FROM AsyncApexJob WHERE Status IN ('Queued', 'Processing')

Fix: throttle the rate of job creation. Use queueable Apex with self-chaining instead of fanning out 1,000 future calls at once.

4. Picklist / multi-select picklist cap

Multi-select picklist values are stored as semicolon-delimited strings. The total stored string can't exceed the field's length cap. With many values selected, you hit the limit.

Fix: change to a junction table (one row per selected value), or shrink the picklist.

How to identify which variant fired

The error message usually includes a clarifier:

EXCEEDED_ID_LIMIT: too many child records under one parent
EXCEEDED_ID_LIMIT: sharing row limit exceeded
EXCEEDED_ID_LIMIT: maximum number of asynchronous jobs reached

If the message is bare EXCEEDED_ID_LIMIT, look at the operation that triggered it — what relationship are you traversing, what insert are you doing — and match it to the table above.

Hard caps you should know

These are platform-wide and not configurable:

  • 10,000 child records under a single master-detail parent
  • 5,000 sharing rows per record
  • 5 million Apex managed sharing rows org-wide
  • 100 future calls per transaction (different cap, but related)
  • 50 queued/in-flight async jobs per user

If your design assumes you can add child records indefinitely under one parent, redesign before you hit the cap in production.

Related dictionary terms