Salesforce blocks a production deployment when overall org-wide code coverage falls below 75%, and every trigger needs at least some coverage of its own. That's the rule most admins can recite. What trips teams up is everything the rule doesn't say out loud: how coverage is calculated, which tests actually run, and why a deployment can fail at 74% when your sandbox swore it was sitting at 82%.

The 75% Number Isn't Per Class

Salesforce checks aggregate coverage across the entire org, not each individual class. A class with zero test coverage can still deploy cleanly if the rest of your codebase carries enough weight to push the average past 75%. This surprises admins who assume every Apex class needs its own passing grade.

The catch is that this average recalculates every time you deploy. Add three new classes with no tests and you drag the whole org average down, even if nothing else changed. A team that was comfortably at 79% can find itself blocked after a metadata-only release that happened to include a handful of untested helper classes.

Triggers get a separate, stricter rule. Salesforce requires at least one line of trigger code to execute during tests, full stop. A trigger with 0% coverage fails validation regardless of what the org-wide number looks like. This is the requirement most first-time deployment failures actually trace back to, not the aggregate percentage.

Why Deployments Fail Even Above 75%

Passing the coverage threshold and passing the deployment are two different events. Salesforce runs your test classes as part of validation, and if any test fails, execution halts regardless of the coverage percentage it would have produced. A single assertion error in an unrelated test class can block a release that has nothing to do with that code.

This is where a lot of "coverage" conversations go sideways. Teams treat 75% as the finish line and stop looking at whether the tests themselves are actually asserting anything meaningful. A test that calls a method and checks nothing is coverage without verification. It satisfies Salesforce's compiler; it does nothing to catch a broken record-triggered flow that fires inside that same method.

Governor limit exceptions inside test execution are another quiet failure mode. Tests that insert bulk records to simulate real load can hit SOQL query limits or CPU timeout limits that never show up in a quick manual sandbox check. The deployment log reports a test failure, but the real story is a limit exception buried three lines into the stack trace.

Run Specified Tests vs Run All Tests

Salesforce gives you three options when deploying to production, and the choice matters more than most release processes acknowledge.

Teams shipping frequent, small releases often default to run local tests and accept the runtime cost. Teams on tighter windows try to shortcut with specified tests, and that's where coverage-related failures creep in silently. If you don't know every class your new metadata touches, you can't reliably name every test class it needs.

Common Coverage Mistakes That Break Production Deploys

Most coverage failures aren't caused by lazy developers skipping tests. They come from structural habits that accumulate over months.

Bulkification gaps are the biggest offender. A test that inserts one record and calls it done will pass in isolation but won't reveal a SOQL-in-a-loop problem that only appears with 200 records. Coverage percentage goes up, actual reliability doesn't.

Hardcoded IDs are the second. A test class referencing a specific record ID from a sandbox will pass there and fail the instant it deploys to an org where that ID doesn't exist. This shows up as a deployment failure with a confusing error message, and it's almost always a five-minute fix once you find it.

Third, and this one's avoidable with better tooling: deploying unrelated metadata bundled together. When a release includes fifteen components and only three actually changed, Salesforce still recalculates coverage against the whole batch. Untangling which component caused a coverage dip means reading through a deployment log that's mostly noise.

Building a Coverage Strategy That Scales

The teams that stop fighting coverage failures share a few habits, and none of them are exotic.

They write tests that assert outcomes, not just execution. A test that checks the actual field values after a trigger fires catches real bugs; a test that just avoids throwing an exception catches almost nothing.

They keep test data creation in reusable test data factories instead of duplicating record setup across dozens of classes. This cuts maintenance time when object schemas change, and it keeps bulk test data realistic across the whole suite.

They also stop treating 75% as a target and start treating it as a floor. An org sitting right at the minimum has zero margin for the next release. One team we've talked to keeps an internal standard of 85%, specifically so a batch of new untested utility classes doesn't put them at risk of failing validation on a routine Friday deploy.

Where Deployment Tooling Actually Helps

None of this is solved by hoping developers remember to write better tests, though that helps too. It's solved by knowing, before you click deploy, exactly which components you're touching and which test classes are actually exercising them.

DeployEzee maps metadata dependencies before a deployment runs, so you can see which Apex classes, triggers, and flows are actually affected by a change set instead of guessing. That matters directly for test selection: if you know the real dependency graph, you can choose run specified tests with confidence instead of defaulting to run all tests out of caution and burning twenty extra minutes on every release.

It also separates sandbox validation from production deployment cleanly, so a coverage number you saw in a full sandbox isn't assumed to carry over unchanged. Production has its own data, its own installed packages, and sometimes its own governor limit pressure. Validating against the actual target org, not a sandbox that resembles it, is the only way to trust the coverage percentage you're looking at before you commit.

Frequently Asked Questions

What is the minimum code coverage required to deploy to Salesforce production?

Salesforce requires at least 75% code coverage across the entire org, calculated as an aggregate, not per individual class. In addition, every trigger must have at least some test coverage, even if the org-wide average is well above 75%. Falling short on either requirement blocks the deployment entirely, regardless of how important the change is.

Can I deploy a class with 0% test coverage if my org average is above 75%?

Yes, for regular Apex classes, since Salesforce checks the aggregate percentage across the org rather than requiring every class to individually pass. The exception is triggers, which must execute at least one line of code during testing no matter what the org-wide average looks like. Relying on this workaround repeatedly is risky, since each untested class drags the next release's average down further.

Why does my deployment fail even though sandbox coverage showed 80%?

Coverage percentages can differ between sandbox and production because of different installed packages, data volumes, or org configuration that changes how tests execute. A test that passes cleanly against a lightly populated sandbox can hit governor limits or fail assertions against production's actual data profile. Always validate against the real target org rather than trusting a sandbox number as final.

What's the difference between run specified tests and run local tests during deployment?

Run specified tests only executes the test classes you explicitly name, which is faster but risks missing a dependency you didn't account for. Run local tests executes every test class in the org except those belonging to installed managed packages, giving broader coverage assurance at the cost of longer runtime. Most teams default to run local tests unless they have precise dependency mapping in place.

Does higher code coverage guarantee a safe deployment?

No. Coverage percentage only measures how much code executed during testing, not whether the tests verified correct behavior. A test that runs a method without asserting its results counts toward coverage but catches no actual bugs. Meaningful coverage requires tests that check real outcomes, like field values or record states, after the code runs.