The Seven Dwarfs in Salesforce Errors: What DOC, GRUMPY and HAPPY Mean and What to Do

TL;DR

• The "Seven Dwarfs" errors are internal Salesforce errors whose text names Bashful, Doc, Dopey, Grumpy, Happy, Sleepy or Sneezy, usually next to common.exception.SfdcSqlException and an Oracle code such as ORA-30006 or ORA-20025.
• Salesforce has never documented what the names mean. Every explanation you will find, including the most-cited Stack Exchange answer, is community conjecture.
• The dwarf is the least useful part of the message. The same failure shows up under different dwarfs. Read the package after the dot (CACCESS, CTASK, CCUSTOMMETADATA, SOPPLINEITEM) and the ORA code: those tell you what failed and how.
• Most reported cases fall into four groups: lock contention, access checks during automation, hidden limits such as file storage, and platform bugs Salesforce has published as Known Issues.
• Some have a workaround you can apply today. Others need a support case, and the case goes faster with the full trace, the steps to reproduce and any ErrorId.

What You'll Learn

• What a dwarf error looks like and how to read each part of the message
• What is known about where the names come from, and what is only rumour
• Which packages appear in real reports, what triggered them, and what fixed them
• The Salesforce Known Issues that contain dwarf traces, with their workarounds
• A short playbook for the next time one appears, including what to put in a support case

The Problem

A user saves a Case, a Web-to-Lead form submits, or a test run that passed yesterday fails. Instead of a validation message, the screen shows something like this:

common.exception.SfdcSqlException: ORA-30006: resource busy; acquire with WAIT timeout expired
ORA-06512: at "DOC.CCUSTOMMETADATA", line ...

There is no field name, no rule name, and nothing a business user could act on. Searching for "DOC.CCUSTOMMETADATA" turns up a handful of forum threads, a GitHub issue and a lot of guessing. The usual advice, "contact support", is right in some cases and a slow detour in others, because several of these errors have known causes and simple workarounds.

These errors have been turning up since at least 2009, and Salesforce developers call them the Seven Dwarfs errors because the names are always drawn from the same seven. This article collects what the public record actually shows: the reported cases, the official Known Issues and the fixes that worked, so you can tell quickly which kind you have.

Common questions this article answers:

• What does DOC, GRUMPY or SNEEZY in my Salesforce error mean?
• Is a dwarf error my code's fault, or a Salesforce problem?
• Can I fix it myself, or do I have to raise a support case?

Quick Answer

When a dwarf error appears:

1. Copy the whole message, including any line that says Please include this ErrorId if you contact support.
2. Read the ORA code. ORA-30006: resource busy means a lock timed out: something else was holding the record or resource your transaction needed.
3. Read the word after the dot, not the dwarf. CACCESS and CTASK point at access checks and Task creation, CCUSTOMMETADATA at custom metadata, SOPPLINEITEM at Opportunity Products, CSTORAGELIMIT at storage.
4. Search Salesforce Known Issues for that package name (for example CCUSTOMMETADATA). Searching for the dwarf name finds nothing.
5. Try the matching workaround from the table further down: retry once, turn off validation rule debug logging, move work into a separate transaction, or free storage.
6. Raise a support case if none of that applies, with the full trace, the steps to reproduce and the ErrorId.

Anatomy of a Dwarf Error

Every dwarf error is built from the same parts. This example comes from a Salesforce Known Issue (W-7581314), trimmed for width:

common.exception.SfdcSqlException:
ORA-30006: resource busy; acquire with WAIT timeout expired
ORA-06512: at "DOC.CCUSTOMMETADATA", line ...
{call cCustomMetadata.load_custmds(...)}

Sometimes the dwarf trace arrives wrapped in an ordinary status code. One reported case showed CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY and "A workflow or approval field update caused an error" with ORA-20067 ... at "SLEEPY.SOPPLINEITEM" underneath. Another showed FIELD_CUSTOM_VALIDATION_EXCEPTION on a validation rule, with a GRUMPY trace inside. When an ordinary-looking error contains a dwarf, treat it as a dwarf error.

Where the Names Come From (and What Nobody Knows)

Salesforce has not published an explanation. The most-cited source is a 2015 Salesforce Stack Exchange question titled Salesforce, Oracle and the Seven Dwarfs, which asked directly what the dwarfs are. Its accepted answer is candid that anyone who knows for certain is probably under a non-disclosure agreement, and it labels its own theories as "wild conjectures".

What the community record does say, with the confidence it deserves:

• The names sit in the platform's database code. A long-standing answer on Stack Exchange describes the Seven Dwarfs as living in the platform code: users should never see them, and occasionally one "breaks out". Another answer from the same contributor describes Salesforce's data operations as running through stored procedures, with the modules named after the dwarfs. These are informed community statements, not Salesforce documentation.
• The same package appears under different dwarfs. Reports show CACCESS under HAPPY, DOPEY, BASHFUL, SLEEPY, SNEEZY and GRUMPY, and CAPEX under DOC, GRUMPY, HAPPY, BASHFUL, SNEEZY and SLEEPY. Which dwarf you see does not seem to say anything about the cause. That is an observation from the reports collected here, not something Salesforce has confirmed.
• They predate most of today's platform. The earliest public sighting found is a 2009 blog post showing a unique constraint error on an Apex class table, raised at "SNEEZY.CAPEX".

What is not known: whether each name is a schema, a server, a pod component or something else, and whether they still appear the same way on Hyperforce. A Salesforce employee answering on the Trailblazer Community in 2019 said nothing they had seen gave a definitive answer on what each dwarf means.

The practical consequence: stop trying to decode the dwarf and read the rest of the message.

The figure below shows where a dwarf error comes from, compared with a normal error. The layer names follow the community understanding above, not Salesforce documentation.

What the Reports Show: Packages, Triggers and Fixes

These are real cases from Salesforce Stack Exchange and Salesforce's own Known Issues. Dwarf names are as reported; the package after the dot is the part to match.

Grouped by cause, nearly every report lands in one of four buckets.

1. Lock contention

ORA-30006: resource busy; acquire with WAIT timeout expired is the most common code in the record. It means the transaction waited for a lock on something another transaction was holding, and gave up. It is the database-level cousin of UNABLE_TO_LOCK_ROW, and the same thinking applies: the cause is concurrency, not the record. Parallel test runs, bulk API bursts, mass email and many children under one parent all raise the odds.

2. Access checks during automation

CACCESS appears in more reports than any other package. The procedure involved checks whether an entity can be accessed. In the cases reported, automation was touching a related record (converting a lead, creating a Task, reading a parent field) in the same transaction as the original save. A Salesforce employee on the Trailblazer Community described the same pattern: automation updating a linked record the user did not have access to update. One Stack Exchange answer also ties dwarf errors to a sharing model change, profile update or cascade delete that was still processing, and says they usually resolve on their own afterwards. If you see CACCESS, read INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY as well, because the underlying question (can this user touch the related record?) is the same.

3. Hidden limits

Some dwarf errors are a limit that should have produced a friendly message and did not. Full file storage behind CSTORAGELIMIT, an entitlement milestone limit that differed between orgs, and a custom field limit on a non-customisable object have all been reported. If a dwarf appears on an operation that normally works, check Storage Usage and the relevant object limits before anything else.

4. Platform bugs

At least five Salesforce Known Issues contain dwarf traces: custom metadata locks (W-7581314), package upload (W-4585783), record merge (W-3689660), permission set save (W-12708544) and ContentNote access (W-3202187). Each has a workaround or a fix version. When the package name matches one of these, you have your answer without a support case.

A Playbook for the Next Dwarf

Use the picker below with the package from your error, then follow the steps after it.

Step 1: Capture everything before it scrolls away. The full message, the user, the time, the record ID, and what was being done. If the message includes Please include this ErrorId if you contact support: 1014169018-81141 (1327239692), keep that line exactly. Known Issue W-4585783 shows an ErrorId and a dwarf trace in the same message.

Step 2: Check it is not a platform incident. Open Salesforce Trust and look at your instance. If there is maintenance or degradation, wait and retry.

Step 3: Search Known Issues by package name. Go to Salesforce Known Issues and search for the package after the dot (CCUSTOMMETADATA, CMETAACCESS). Searching for SfdcSqlException or ORA-06512 also works. Searching for the dwarf name returns nothing.

Step 4: Look at what else ran in the same transaction. A debug log for the affected user shows every trigger, Flow and validation rule involved. Dwarf errors in the reports above almost always involve automation doing a second thing (convert, insert Tasks, update a parent, generate a PDF) inside the first thing's transaction.

Step 5: Apply the matching fix.

• Lock timeout (ORA-30006): retry once, after the competing work finishes. Then reduce concurrency: smaller batches, fewer parallel jobs, sort records by parent before DML. For test runs, try with parallel testing turned off (Setup → Apex Test Execution → Options).
• Custom metadata in a validation rule: set the Validation debug log category to NONE for the user running the integration or tests.
• CACCESS with automation: move the second action to a later transaction (a Queueable, a scheduled path in Flow, or a time-based action), and check the running user's access to the related record.
• Limits: free file or data storage, or check the object limit involved.
• Save of setup metadata (permission set, package upload): retry the save, as the Known Issue workarounds suggest.

Step 6: Raise a support case if nothing matches. Include the full trace including the dwarf line and the procedure call, the ErrorId, exact steps to reproduce, the record IDs, and whether it happens every time or intermittently. Salesforce's own guidance on internal errors asks for the ErrorId and how you got there. A case that only says "DOC error on save" is hard to triage. One with a reproducible trace is not.

What Not to Do

• Do not show dwarf text to end users. One reported case surfaced the dwarf trace on a Visualforce page because the controller passed the raw exception to ApexPages.addMessages(e). Catch the exception, log the full detail for yourself, and show the user a plain message.
• Do not retry in a loop. If the cause is lock contention, automated retries add to the contention. Retry once, then fix the concurrency.
• Do not grant broad permissions to make a CACCESS error go away. Work out which related record the user could not reach, the same way you would for INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY.
• Do not trust Trailblazer Community links to stay up. Salesforce has announced the community becomes read-only on 30 October 2026. Save the details of any thread you rely on in your own notes or case.

Frequently Asked Questions

Q: What do the dwarf names in Salesforce errors actually mean?

A: Salesforce has never said. The community understanding is that they are names inside the platform's database code, which normal error handling should hide. In the reported cases, the same package appears under different dwarfs, so the name does not tell you the cause. Read the package after the dot and the ORA code instead.

Q: Is a dwarf error caused by my code?

A: Often partly. The error comes from Salesforce's internals, but in most reported cases something in the org made it more likely: automation doing extra work in the same transaction, concurrent jobs competing for locks, a validation rule reading custom metadata while debug logging was on, or a full storage allocation. Change those and the error often stops, even though your code never threw it.

Q: Will Salesforce support help with a dwarf error?

A: Yes, these are internal errors, so support is the right place when there is no known workaround. Give them the full trace, the ErrorId if present, the steps to reproduce and whether it is intermittent. Check Known Issues first, because several dwarf errors already have a published workaround or fix.

Q: Why does the dwarf change when the same error happens again?

A: Nobody outside Salesforce knows for certain. What the reports show is that the package name and procedure stay the same for the same operation (for example CACCESS and cTask.insert_tasks for Task creation after Web-to-Lead) while the dwarf name changes. Match on the package, not the dwarf.

Q: Do these errors still happen?

A: Reports run from 2009 to recent years, and Salesforce Known Issues still list SfdcSqlException errors, although some recent entries show non-Oracle database messages without a dwarf. Whatever the storage layer underneath, the approach is the same: read the package and the error code, check Known Issues, and look at what else ran in the transaction.

Key Takeaways

• A dwarf error is an internal Salesforce database error that escaped normal error handling
• Salesforce has never explained the names, and the dwarf itself does not point to the cause
• The package after the dot and the ORA code are the useful parts: ORA-30006 is a lock timeout, CACCESS is an access check, CCUSTOMMETADATA is custom metadata
• Most reported cases are lock contention, access checks during automation, hidden limits, or published platform bugs
• Search Known Issues by package name, not by dwarf
• Common fixes: retry once, move extra work into a separate transaction, turn off validation rule debug logging, free storage
• When nothing matches, a support case with the full trace, ErrorId and reproduction steps is the fastest route

What's Next?

Recommended reading:

• UNABLE_TO_LOCK_ROW: The Error That Is Really About Your Data: the everyday form of the lock contention behind ORA-30006
• INSUFFICIENT_ACCESS_ON_CROSS_REFERENCE_ENTITY: The Error Names the Wrong Record: the access question behind most CACCESS cases
• Salesforce Outage Recovery Runbook: what to check and when, when the problem is the platform

Action items:

1. Check whether any validation rule in your org reads custom metadata, and make sure integration and test users do not run with Validation debug logging on
2. Find any controller or Flow screen that shows raw exception text to users, and replace it with a plain message plus logging
3. Add "search Known Issues by the package after the dot" to your team's support runbook

Resources & References

• Salesforce, Oracle and the Seven Dwarfs: Salesforce Stack Exchange: the canonical question, with the main community theories and their caveats
• Seven Dwarfs in the platform code: Salesforce Stack Exchange answer: the long-standing community description and the advice to contact support
• Known Issue W-7581314: Account update fails due to Custom Metadata lock: DOC.CCUSTOMMETADATA, with the debug log workaround
• Known Issue W-4585783: package upload error: an ErrorId and a SNEEZY.CMETAACCESS trace in the same message
• Known Issue W-3689660: merge error display: a dwarf trace hiding an ordinary validation error
• Known Issue W-12708544: permission set save: BASHFUL.UDDDMLSETUPENTITYACCESS, fixed by saving again
• rflib issue #34: Seven Dwarfs errors in unit tests: a worked example of the custom metadata lock, with Salesforce Support's workaround
• What Is A Gack?: Salesforce Engineering blog: what Salesforce needs from you when an internal error occurs
• Salesforce Known Issues: search by package name or SfdcSqlException