Case Study: The 100-Product Opportunity That Hit Governor Limits

Some Salesforce bugs are subtle.
Some are dramatic.
And some are so catastrophic that the platform itself steps in and says:

“No. Absolutely not. Stop what you’re doing.”

This is a story about the third kind — a real project, a real failure, and a lesson every Salesforce tester must learn.

The Setup
The client had a custom automation running on Opportunity close.
Nothing unusual:

• create invoicing records
• update related data
• run a few calculations

On paper, it looked harmless.

Then one day, a Sales Rep added over 100 products to an Opportunity.

And everything collapsed.

The Symptom
When the Sales Rep clicked Close, Salesforce threw:

“To Many SOQL Queries.”

That’s the Salesforce equivalent of a car engine exploding while parked.

First Debug Attempt
Developers tried reproducing it with:

• 5 products
• 10 products
• 20 products

Everything worked.

Then I tried it with:

• 100 products

Boom. Same error.

Root Cause: The Hidden Cost of Loops
Inside one of the Apex classes, we discovered something like this:

for(Productc p : opportunity.Productsr)

// inside this loop… another SOQL query

// another

//another etc.

}

This is the Salesforce version of:

“Let me call the bank once… for every coin in your wallet.”

Governor Limits allow 100 SOQL queries per transaction.
100 products = more than 100 queries → system explodes.

Why No One Saw It Earlier
Because testers, developers, and consultants all tested the logic
with “nice, clean, elegant test data.”

5 products.
8 products.
A small, polite number of products.

Meanwhile in production, users behave like users.
They add:

• 48 products
• 73 products
• 113 products

Because why not?

The Fix
The developer rewrote the logic to:

• perform a single SOQL query
• handle all products in memory
• update related data using bulk patterns

A classic bulkification fix.

Later, the entire opportunity-closing process was refactored, but for one client, L1 Support had to close two opportunities per year. It was easier than refactoring part of the code that was broken.

The Lesson for Testers
Here’s the key:

If your test data is always clean, tidy, and predictable —
you will never find Salesforce performance bugs.

To catch issues like this, you must intentionally test:

• maximum record counts
• unusual combinations
• edge-case data volumes

Automation is written by people.
People assume the world is tidy.
Users prove them wrong.

How to Avoid This in the Future
Here’s a simple rule:

Always test one scenario with excessive data.
Not because it’s required.
Because it’s dangerous not to.

Test:

• Opportunities with 100+ products
• Cases with dozens of child records
• Accounts with large related lists

Salesforce gives you governor limits for a reason:
to remind you that the platform is shared — and unforgiving.

Final Thoughts
The next time someone says “It’s just a simple automation,”
remember the 100-product Opportunity.

And test like a user who doesn’t care about governor limits.

Because they don’t.
But you must.

If you want another case study (Process Builder migration disaster), it’s coming next.