By Tomasz Teodorowicz — 26 Feb 2026

The Feature That Worked Until It Didn’t

The Time Bomb in Your Org

There is a specific type of Salesforce failure that is more painful than any other. It isn’t the immediate crash upon deployment. It isn’t the obvious logic error found in UAT.

It is the feature that works perfectly. It works for a week. It works for a month. The users love it.

Then, on a Tuesday morning at 9:00 AM, it stops.

It hits a System.LimitException. It throws a CPU Time Out. It locks the database.

The developers scramble. The stakeholders panic. And someone asks the inevitable question:

"But didn't we test this?"

Yes, we did. But we tested it in a vacuum. We tested the functionality, but we ignored the context. We didn't test for scale.

Why Scale Is Ignored

Early testing usually happens in environments that are dangerously optimistic:

Developer Sandboxes: Often contain less than 1% of Production data.
Demo Data: Perfectly structured records with no weird edge cases.
Ideal Conditions: No other users are logged in, no background jobs are running, and the queues are empty.

In this environment, everything is fast. A query runs in 3 milliseconds. A Flow finishes before you can blink. The system feels ready.

But this isn't a test environment. It’s a simulator of a perfect world that doesn't exist.

What Changes with Scale

Scale in Salesforce isn't just about "slowness." It is about Governor Limits and Architecture. When data volume and user concurrency increase, the fundamental behavior of the platform changes.

1. The Query That Chokes

In Sandbox, [SELECT Id FROM Account] returns 50 records. It’s instant.
In Production, that same query attempts to return 500,000 records.

The Result: The transaction hits the 50,000 record retrieval limit and crashes.
The Fix: The query wasn't "selective." It worked only because the dataset was small.

2. The Flow That Stacks

You built a Record-Triggered Flow. You tested it by updating one record. It worked.
Then, an integration updates 200 records at once via the API.

The Result: Your Flow fires 200 times in a single transaction. If your logic isn't "bulkified" (e.g., performing a SOQL query inside a loop), you hit the limit of 100 queries immediately.
The Crash: The entire batch fails, and the integration retries, creating a spiral of failure.

You change the owner of a record. In Sandbox, it saves instantly.
In Production, that record has 10,000 related child records, and the new owner is part of a complex hierarchy.

The Result: Salesforce has to recalculate access for every child record. The save takes 15 seconds, or worse, times out.

Nothing changed in the code. Reality changed.

The QA Gap

Many QA teams focus exclusively on:

Functionality: "Does it calculate the right number?"
UI Behavior: "Does the modal open?"
Correctness: "is the data saved?"

Few teams explicitly test:

Volume: "What happens if I load 5,000 records?"
Concurrency: "What happens if two users save at the exact same millisecond?"
Ownership Skew: "What happens if the user owns 100,000 records?"

These are not edge cases. In a successful company, scale is an inevitability.

The Uncomfortable Truth

If you haven’t tested your logic against a bulk dataset, or verified how it behaves with 200 records in a single transaction, you haven't tested the feature.

You have tested a prototype.

A prototype proves the concept works. A test proves the concept survives.

The Mindset Shift: Scale Is Correctness

We need to stop treating performance and scale as "Non-Functional Requirements" handled by architects.

Scale is a correctness topic.

If a feature works for one record but fails for ten, it is functionally broken. If a feature works for the first 1,000 users but locks out the 1,001st, it is a defect.

QA Takeaways

Test in Bulk: Never consider a Flow "Done" until you have triggered it with a batch of 200 records.
Simulate the Skew: If the Production Org has "Data Skew" (Accounts with >10k Contacts), recreate that in the Sandbox.
Watch the Limits: Use the Debug Log to check how close you are to the limits. If a single operation consumes 70% of your SOQL queries, it will fail in Production.

Salesforce doesn’t fail at scale. Assumptions do.

When was the last time a "Bulk API" update broke your "perfect" Flow?