
Andrew Hanna

Andrew Hanna

TL;DR: A click deploy rarely fails because of the button. It fails because the Salesforce Metadata API rejects the package, and almost every rejection falls into five groups: a missing dependency, too little test coverage, an API version the target does not know, a platform size limit, or a change the API cannot make. Read the first error, fix the cause in the source, and validate again before you deploy.
Whatever tool you click in, the same thing happens underneath. The tool builds a
package.xml manifest and a .zip of the selected metadata, sends it to the
Metadata API, and Salesforce compiles it, runs Apex tests at the chosen test level,
and saves the result. If you are new to point-and-click tools, start with
how ClickDeploy works and what it costs.
Two platform rules explain most surprises:
The package references something the target org does not have: a field without its object, a Flow without the fields it reads, a child object without its parent. Copado Essentials, the tool formerly called ClickDeploy, documents a classic case: deploying a detail object alone returns Cannot set sharingModel to ControlledByParent on a CustomObject without a MasterDetail relationship field. Its fix is to add the parent object to the deployment, even if it has not changed.
Salesforce requires at least 75% of your Apex to be covered by unit tests to deploy to production, and every trigger needs at least one covered line. If you choose RunSpecifiedTests, the bar changes: the tests you name must cover 75% of each class and trigger in the package on its own. The fix is better tests, not a different test level.
An error such as Invalid api version usually appears around a release window, when your sandbox already runs the next Salesforce release and production does not. Winter '27 is a live example: sandboxes moved to preview in late August 2026, while production instances upgrade over several weekends into October, so check your instance on Salesforce Trust. Copado's guidance is to set the component's API version back to one production supports, then redeploy.
Salesforce's own deploy library, source-deploy-retrieve, warns as a deployment approaches the Metadata API limits of 10,000 files and about 39 MB zipped. Wildcard selections and whole-object deploys hit these first. Split the release, or ship only what changed with delta deployments.
A green deploy only means Salesforce accepted the package. It does not mean the target matches the source:
Tekunda is the Salesforce consulting and product company behind Serpent, the DevOps platform it runs on its own client delivery. Serpent keeps the click-to-select experience, but every change travels through Git, a pull request and a validation with Apex tests before it reaches the next org, with AI code review on every plan, including the free one. It installs nothing in your org. Teams on Copado Essentials, Gearset, Salto, AutoRABIT, Flosum or Blue Canvas can follow our migration path, and more how-tos live in the SF Guides library.
Why does my deployment pass in a sandbox but fail in production?
Sandboxes run no Apex tests by default, while production runs local tests and enforces 75% coverage. Validate against production with the same test level first.
What does "invalid api version" mean?
Your component uses an API version the target org does not support yet, usually during a release window. Lower the component's version and redeploy.
Can I ignore errors and deploy anyway?
The Salesforce CLI has an ignore-errors flag that skips the rollback, but its own reference says never to use it in production.
How many components can one deployment hold?
The Metadata API caps a deployment at 10,000 files and about 39 MB zipped. Split larger releases.
Commitment free!