Click Deploy Checklist: How to Run a Safe Point-and-Click Salesforce Deployment

TL;DR: A click deploy moves Salesforce metadata from one org to another by selecting components in a UI instead of building a change set or typing CLI commands. To run one safely, compare the orgs, add dependencies, validate with a deliberate Apex test level, then quick deploy the validated package and verify it. The full checklist is below.

What is a click deploy in Salesforce?

"Click deploy" is shorthand for point-and-click deployment: a tool compares a source and a target org, shows what changed, and deploys the components you tick. The name comes from ClickDeploy, which Copado acquired in 2020 and now sells as Copado Essentials; we cover its history and pricing in how ClickDeploy works and what it costs. Copado Essentials, Gearset and other click-based tools all hand the final package to the Salesforce Metadata API, so the platform's rules apply whichever tool you click in. That is why this checklist works everywhere.

How do you run a safe click deploy, step by step?

1. Refresh the comparison. Compare source and target right before you deploy, not the day before. Someone may have changed the target since.
2. Select the change, then its dependencies. A new field needs its object, and a Flow may need fields, Apex classes or permission sets. Most tools flag missing dependencies; trust the flag, not memory.
3. Keep the package small. Ship only what changed. Salesforce caps a deployment .zip at 39 MB, as Gearset's documentation notes, and small packages are easier to debug. Delta deployments make this the default.
4. Plan deletions separately. Removals travel in destructive-change manifests, which the Salesforce CLI applies either before or after the deploy. Choose the order based on what still references the component.
5. Validate first. Run a check-only validation. It runs Apex tests and reports errors without saving anything to the org.
6. Pick the test level on purpose. The default is not always right; see the next section.
7. Quick deploy the validated package. In production, a successful validation can be released later without re-running Apex tests. The CLI reference says the job ID stays valid for 10 days from the start of validation, so you can validate in the afternoon and release in a quiet window.
8. Verify and record. Open the changed pages, run a quick smoke test and note exactly what shipped, so a rollback has something to roll back to.

Which Apex test level should you choose?

The Salesforce CLI documents five test levels, and most click tools show the same list under friendlier names:

• NoTestRun: no tests. Allowed only for development environments such as sandboxes, Developer Edition and trial orgs.
• RunSpecifiedTests: only the tests you name. Gearset's guide notes that each class or trigger in the package then needs 75% coverage on its own.
• RunLocalTests: every test except those from installed managed and unlocked packages. It is the default for production deployments that include Apex classes or triggers.
• RunAllTestsInOrg: everything, managed package tests included.
• RunRelevantTests (beta): Salesforce picks tests by analysing the payload and its dependencies. It needs API version 66 or later.

Be careful with RunRelevantTests in production. Bob Buzzard's Spring '26 testing found it picked tests with direct dependencies on the changed code but missed indirect chains and dynamically instantiated classes. Mark must-pass tests with @IsTest(critical=true) before you rely on it.

When is a click deploy the wrong tool?

• More than one person ships to the same org. Org-to-org deploys keep no shared history, so the second deploy can overwrite the first.
• You need a dependable rollback. Rolling back is easiest when every release was committed before it shipped.
• You ship a managed package. ISVs release package versions to subscribers, not org diffs; see second-generation managed packages.

Leaving org-to-org deploys behind does not mean leaving clicks behind. Admins can keep selecting changes in a UI while the tool writes the Git commits, as we show in DevOps for admins without touching Git.

How does Tekunda handle click-based deployment?

Tekunda is the Salesforce consulting and product company behind Serpent, the DevOps platform it also uses for its own client delivery. Serpent keeps the click-to-select experience: you pick changes, attach them to a ticket and promote them through your pipeline, while Git, pull requests, validation and Apex tests run underneath, with AI code review on every plan. It installs nothing in your org and starts free, with flat team pricing on our pricing page. More walkthroughs live in the SF Guides library.

FAQ

Is a click deploy the same as a change set?

No. Both move metadata between orgs, but a click tool builds the package from an org comparison instead of you adding components to a change set one by one.

How long can I wait between validation and quick deploy?

Up to 10 days from when the validation started, according to the Salesforce CLI reference.

Do sandbox deployments run Apex tests?

Not by default. Salesforce's default level runs no tests in a sandbox, while production deployments that include Apex classes or triggers run local tests.

Can I click deploy for free?

Yes. Copado Essentials has a free tier of up to 15 deployments a month for one user, and Serpent also offers a free plan.