Salesforce quick deploy: validate first, then ship to production in minutes

A production deployment is slow for one reason: Salesforce runs your Apex tests while the release window ticks away. In an org with a large test suite that can take hours, and if a single test fails near the end, the whole deployment rolls back and you start again. Validation and quick deploy exist to move that risk out of the release window. You run the slow, risky part days earlier, and on release day you ship the package that has already passed.

It is a simple idea with several rules attached, and most of the frustration ("why has the Quick Deploy button vanished?") comes from the rules. This guide covers how it works, what each test level actually runs, why a validation stops qualifying, and a release routine that fits the rules.

What validation and quick deploy are

A validation is a deployment with the check-only option switched on. Salesforce does everything a real deployment does, including running tests, and then rolls it back. Nothing is saved in the org, and you see the same component errors and test failures a real deployment would produce.

A quick deploy takes a validation that passed and deploys it without running the tests again. You can start one in three places:

• In Setup, on the Deployment Status page, with the Quick Deploy button next to a qualifying validation. Salesforce Help says it works for change sets as well as Metadata API deployments.
• Through the Metadata API, by calling deployRecentValidation() with the validation's ID.
• With the Salesforce CLI, using sf project deploy validate, which returns a job ID, followed by sf project deploy quick --job-id <id>.

The CLI documentation describes the pattern as most useful when a production deployment takes hours and you do not want to risk a failed one. That is the case it was built for.

The five test levels, and what each one means for coverage

The test level you validate with decides which tests run and which coverage rule applies. Salesforce documents five:

Two details trip people up.

First, if you do not name a level when you deploy to production, Salesforce chooses from the package contents. If it contains Apex classes or triggers, all local tests run. If it contains no Apex, no tests run. Salesforce recommends running all local tests in a development environment such as a sandbox before you deploy to production. That is also where a failing test is cheapest to fix.

Second, the per-class rule for RunSpecifiedTests is stricter than it looks. An org can sit at 90% coverage overall and still fail a specified-tests deployment, because one class in the package is covered too thinly by the tests you named. The tests you pick have to cover every class you ship.

RunRelevantTests is worth watching. Salesforce describes it as a way to avoid both the long runtime of RunLocalTests and the hand-picked test list that RunSpecifiedTests needs, and it lets you steer the selection with @IsTest(critical=true) and @IsTest(testFor='...'). It is still labelled beta in Salesforce's documentation, so treat it as something to trial in a sandbox rather than rely on for a release.

When quick deploy is available

Salesforce Help lists three requirements:

1. The components were validated successfully against the target org within the last 10 days.
2. The Apex tests in the target org passed as part of that validation.
3. The coverage rule for the test level was met.

If all three hold, the Quick Deploy button appears. If any one fails, it does not. When the button is missing, check these five causes.

1. The validation is more than 10 days old

The window is 10 days from the validation. The job ID the CLI returns has the same lifetime.

2. The validation did not run any tests

With no test results, there is nothing to reuse. A deployment to a sandbox runs no tests by default, and a production package with no Apex runs none either. Salesforce Help says quick deploy in a sandbox is supported only for validations that explicitly turned tests on.

If your package is metadata only (a field, a layout, a flow) and you still want a quick-deployable validation, set the test level yourself. Salesforce enforces the level you choose whatever the package contains.

3. A test failed, or the coverage rule was not met

Check which rule applies to your level: overall coverage for the local and all-tests levels, per class for specified and relevant tests.

4. Something else was deployed after the validation

This is the one that catches teams out. Salesforce Help says that if you deploy after a validation, whether through a quick deploy, a package installation or a regular deployment, earlier validations stop qualifying and you need to revalidate. A late hotfix, or a package upgrade someone installed the night before, voids the validation you timed so carefully.

5. You validated against a different org

A validation belongs to the target it was run against. A validation against a UAT sandbox cannot be quick-deployed into production. You need a validation against production itself.

A release routine built around the rules

1. Test in a sandbox first. Run all local tests there, as Salesforce recommends, and fix what fails before production is involved.
2. Validate against production a few days early. Use RunLocalTests, or RunSpecifiedTests when you have a reliable list. Note the time, because the 10-day clock starts at validation.
3. Fix and revalidate until it is green. Read the component errors, test failures and coverage warnings now, not in the release window.
4. Freeze other deployments to production. From validation to release, nothing else goes in: no hotfixes, no package installs, no other team's change set. Because any deployment voids earlier validations, the freeze is a rule rather than a courtesy.
5. Quick deploy in the window. Salesforce runs one deployment at a time per org and queues the rest, so check nothing else is waiting ahead of you.
6. Verify and keep the record. A quick deploy is still a deployment, and a successful one has no automatic undo. Keep the validation record and the package contents so you can plan a reversal if you ever need one.

Doing this in orgadmin.ai

The Deployments feature builds the package from a comparison instead of from memory. Pick a source and a target org and the metadata types, read the classified diff (every component is new, changed, unchanged or deleted, with side-by-side differences) and tick what ships. Then:

• Validate. A production target defaults to a check-only validation. To run a real production deployment you untick "Validate only" and confirm an extra production prompt. You choose the test level: the default (which follows Salesforce's usual rules for the target), specified tests with a class list the dialog remembers, local tests, or all tests.
• Quick deploy. When a validation that ran tests finishes with no component errors, the run page offers a quick deploy for 10 days. It calls deployRecentValidation(), so the validated components and test results are reused and nothing is retrieved or retested. If Salesforce refuses it, for example because something else was deployed in between, the run ends with Salesforce's error message and you validate again.
• When the validation ran no tests, Salesforce has nothing to reuse. For a validation built from an org comparison or from a Development Studio project, the app offers a one-click full redeploy of the same components instead. That is an ordinary deployment built from your source as it stands now, not a frozen copy of the validated package, so Salesforce's usual test rules apply again.

The safeguards sit around all three. Validating and deploying are limited to workspace owners and admins, production needs the explicit confirmation, and only one deployment can be active against a target org at a time, so two runs cannot interleave. Only components that came from the comparison can be deployed, every run stores its package.xml manifest and a content hash, and every action is audit-logged.

There are limits worth knowing before you commit to it:

• Four test levels, not five. The deploy dialog offers no tests, specified tests, local tests and all tests. RunRelevantTests is not offered while Salesforce has it in beta.
• No automatic rollback. The stored manifest and hash support manual planning only, and deployments never delete components that exist only in the target.
• No git, branching or scheduled pipelines. This suits a team that releases by hand. If you need promotion pipelines, read do you need a Salesforce CI/CD pipeline first.

If a validation fails, why Salesforce deployments fail explains how to read what comes back.

Quick answers

Can I quick deploy to a sandbox? Salesforce supports it only for validations that explicitly ran tests, and its CLI documentation says the validate and quick commands are intended for production. In a sandbox, use a normal deployment and choose a test level if you want tests.

How long does a validation last? Ten days.

Does a quick deploy run my tests again? No. It reuses the results from the passed validation.

Does quick deploy work for change sets? Yes. Salesforce Help says quick deployments are available for change sets and for Metadata API components.

Do I have to run every test to qualify? No. A validation with RunSpecifiedTests can qualify, provided each class and trigger in the package is covered at least 75% by the tests you named.

Try it on a sandbox first

Validate a small change against a sandbox with a test level chosen, and read how the run reports it. Start a free orgadmin.ai trial, connect two orgs and compare them before you plan your next release.

Sources and further reading

• Monitor Deployments (Salesforce Help): quick deployment requirements and the Deployment Status page
• deployRecentValidation() (Metadata API Developer Guide)
• Running Tests in a Deployment (Metadata API Developer Guide)
• Run Relevant Apex Tests in a Deployment (Beta) (Metadata API Developer Guide)
• project deploy validate, project deploy quick and project deploy start (Salesforce CLI Command Reference)