Salesforce ISV Testing: What to Watch Before You Ship

If you’re building a managed package on Salesforce, the first time your code fails won’t be in your dev org. It’ll happen in a customer sandbox you’ve never seen, running on config you didn’t create and data you didn’t expect. That’s the challenge with Salesforce ISV testing: you don’t ship into a clean slate, you ship into potential chaos.

That’s the ISV reality. You’re not just shipping code. You’re shipping trust into environments you don’t control.

The technical side of packaging is well documented. The testing side isn’t. And most ISVs learn that the hard way.

Here’s what makes ISV testing different, what usually goes wrong, and how to build confidence into your releases before you upload your next version.

Why ISV testing is a different game

Most Salesforce teams test what they own. Their metadata. Their flows. Their users and data.

ISVs don’t get that luxury. Your code lives in a namespace. It gets deployed into orgs with automation, objects, and installed packages you didn’t write and can’t predict. Admin access isn’t guaranteed. Clean metadata is rare. And you definitely can’t guess what your customers have already installed.

Every org becomes a new edge case. Every upgrade carries real risk.

That’s why you need two test tracks:

• One in the packaging org, where your code and logic live
• One in the installation org, where your product actually runs

It’s not just about whether your features work. It’s about whether they still work after someone else hits install.

If you’re new to ISV delivery, Salesforce offers a Trailhead module on managed package development that explains the basics.

Where things tend to go wrong

We’ve seen ISVs ship updates with a passing test suite and no errors, only to face a flood of support tickets from pilot customers. The issues usually don’t show up in clean pipelines. They surface in the real world:

• Apex classes break when another installed package creates naming conflicts
• Flows misfire when managed fields are referenced in unexpected automation
• Test data scripts fail silently because the expected objects don’t exist
• Components vanish from pages due to field-level visibility or profile differences
• Post-install scripts overwrite data or fail in partial copy sandboxes

And these are just the obvious ones.

Most of these issues aren’t bugs. They’re mismatches, caused when your assumptions about structure, access, or behavior collide with a real customer org.

What solid Salesforce ISV testing looks like

The best ISV teams approach testing in layers.

They start in the packaging org, with tests that cover:

• Core logic and Apex
• Public API endpoints
• Feature-specific flows
• License-based behavior
• Post-install and upgrade automation

These run fast and often. But they don’t catch everything.

That’s why smart teams build a second layer in installation orgs, where they simulate the real customer experience:

• Installing into fresh scratch orgs
• Running flows with restricted permissions
• Verifying UI layouts and metadata visibility
• Testing version-to-version upgrades with live data
• Validating uninstall, reinstall, and rollback paths

That second layer is where Salesforce ISV testing really earns its keep.

This kind of testing takes more time. That’s also what makes it worth doing. It’s where the biggest risks live and where trust is won or lost.

The most common blind spots

ISVs often assume passing security review means they’re ready. But the AppExchange review isn’t designed to test upgrade behavior, config conflicts, or permission boundaries. It catches vulnerabilities, not breakage.

Confidence doesn’t come from perfect coverage. It comes from seeing how your product holds up in the kind of environments you can’t predict but still have to support.

We’ve worked with teams that had clean pipelines and stable builds, but still lost customers because a post-upgrade flow wiped out field settings in orgs where that feature had never even been used.

Nothing technically failed. But the user lost trust, and the admin uninstalled.

Most teams fail not because their tests are wrong, but because Salesforce ISV testing wasn’t built with upgrade safety in mind.

If you’re exploring the broader challenges of test strategy across Salesforce teams, you might also like our post on Salesforce QA Strategy.

A different kind of ownership

As an ISV, you’re accountable for things you don’t control. That’s a tough spot. But it’s also where the right testing strategy makes all the difference.

You won’t see every customer org, and you won’t prevent every conflict. But you can simulate the most likely ones and turn your test process into something that builds trust, not just checks boxes.

Want to test smarter across environments?

If you’re building or maintaining a Salesforce managed package and want to test it the way your customers experience it, we can help. Explore our Salesforce QA services or book a QA assessment tailored for ISV teams.

This article first appeared on springburst.io: the home of smarter Salesforce testing and quality assurance, cultivating quality for customer success.

Want to see how we apply this mindset in real-world Salesforce QA and test automation? Visit springburst.io: we’re cultivating quality for customer success.