Deployment Pre-Flight Pack

“Succeeded” is the most dangerous word in a deployment

A Salesforce deployment reports success when every component in the package deployed and every test passed. That is a narrower claim than most teams hear. It says nothing about whether the components you did not include exist in the target org.

This is why deployments succeed and applications break minutes later. The metadata landed. The thing it depends on did not.

Dependencies the validator cannot see

The twenty-eight entries in this pack are all variations of one failure: a component references something outside the package, and the target org does not have it. Apex referencing a field you forgot to include. A Permission Set granting field-level security on a field that does not exist yet. A Flow calling a subflow that was never deployed.

Some of these fail loudly at deploy time. The dangerous ones do not — they deploy cleanly and fail at runtime, for users, hours later. Each entry pairs the failure with the pre-flight check that catches it before you deploy.

Data is not metadata

A recurring category deserves separate mention: things that look like metadata but are data. Picklist values, Record Types, and the records that Flows and Apex look up by name all fall here. A deployment moves the field; it does not necessarily move the values inside it.

The pack covers which of these travel with a deployment, which do not, and how to verify the target org before you find out from a user.

Templates and sequence

Two practical inclusions. Ready-to-use package.xml and destructiveChanges.xml templates, because destructive deployments are the ones most teams have never practised and most need to get right first time. And the Validate + Quick Deploy sequence, which runs the full validation against production ahead of time so the actual deployment window is minutes rather than an hour of held breath.