12 Salesforce Deployment Interview Questions: Validation to Rollback

Strong answer

I start with the delivery model, not the tool name. I ask whether source control is authoritative, how many teams contribute, which metadata types are involved, whether environments use source tracking, whether releases must be repeatable across several orgs, and whether the solution is an internal application or a versioned product.

For a source-driven team, Salesforce CLI or DevOps Center can support reviewable artifacts and automated validation. Change Sets can work for a smaller org-to-org administrative release, but I still need a documented component list and repeatable pre- and post-deployment steps. Unlocked or managed packages may be appropriate when versioning, dependency management, or distribution justifies that lifecycle.

The interview point is traceability: can the team recreate exactly what was tested, identify who approved it, and promote the same artifact without manually rebuilding the selection?

Strong answer

A shared sandbox can contain unrelated work, experiments, admin changes, incomplete dependencies, and changes already made in another branch. Deploying every detected difference expands the blast radius and makes review, testing, and recovery harder.

I define a release manifest or package boundary from reviewed source control. Before promotion, I inspect the deployment preview, ignored files, deletions, target-org differences where source tracking is available, and any manual production changes recorded in Setup Audit Trail.

I do not resolve a conflict by automatically overwriting the org. First I determine which version is authoritative, reconcile it in source control, rerun tests, and regenerate the artifact. A clean command is not more important than preserving the correct behavior.

Strong answer

I build a dependency map from references, not from file timestamps. A component can compile only when the fields, classes, labels, named credentials, custom metadata, record types, or other resources it references exist in the target org.

A practical sequence begins with foundational object metadata, then code and user-interface components, then automation, permissions, and sharing where the feature permits that separation. I also identify circular or same-transaction dependencies that must be deployed together.

The metadata sequence is only part of the release. Named credential principals, certificates, connected-app policies, endpoint allowlists, users, queues, custom-setting values, and environment-specific custom metadata can require controlled setup. I never copy a production secret into source or assume a successful metadata validation proves an external dependency is configured.

Strong answer

Their retrieved metadata is context-sensitive. The permissions represented can depend on which objects, fields, classes, tabs, applications, and other components were included in the retrieval. A partial artifact can therefore omit an intended setting, while a large profile deployment can change more access than the feature requires.

I prefer focused permission sets for additive feature access and include the referenced components in the same reviewed release boundary. I compare the target result, not just the XML diff: which persona can read, create, edit, delete, execute, or view each relevant object, field, Apex class, Flow, tab, and app?

I test a least-privileged user after deployment. A System Administrator smoke test cannot prove that permissions were transported correctly, and a visible page does not prove field- or record-level access is correct.

Strong answer

A sandbox dry run checks the artifact against a development or test environment without committing the metadata. It is valuable for dependency, compilation, and test feedback, but it does not prove the production org has the same configuration, data shape, installed packages, limits, or test behavior.

A production validation checks the deployment against the actual target org and runs the selected tests without saving the components. If it succeeds with the required tests and coverage, the returned job ID can qualify for a later quick deploy.

I use both. Target-like sandbox testing gives the team room for regression, user acceptance, integration, performance, and data-migration rehearsal. Production validation catches target-specific metadata and test problems close to release. Neither replaces post-deployment business verification.

Strong answer

I choose from release risk and coverage semantics. RunLocalTests runs local tests while excluding tests that originate from installed managed packages, and it is the normal production default when Apex is included. It provides broad regression evidence across the org’s code.

RunSpecifiedTests can shorten a targeted deployment, but the named tests must cover each deployed class and trigger to the required individual level. That is different from meeting one overall org-wide percentage. I maintain an explicit mapping from changed behavior to tests and include downstream callers, sharing, asynchronous jobs, and failure paths—not only tests whose names match the classes.

I do not use coverage as the quality target. Assertions must prove business outcomes, bulk behavior, permissions, negative cases, and error handling. High line coverage can still miss a broken release.

Strong answer

No. I first confirm the validation is still eligible, the exact artifact and target org are unchanged, no intervening deployment disqualified it, and the release remains within the validity window. I store the validation job ID with the commit, manifest checksum, test result, target org, time, and approver.

A quick deploy skips rerunning tests because they ran during the qualifying validation; it does not repeat the analysis against a newly assembled artifact. If the source changed after validation, I build a new artifact and validate again.

I also keep the release window long enough for post-deployment steps and verification. Saving test time is useful, but a quick metadata deploy does not make data migration, permission assignment, cache behavior, integration activation, or smoke testing instantaneous.

Strong answer

I use an expand-and-contract sequence. First add the new field or structure and deploy code that can tolerate both old and new representations. Backfill data in controlled batches, reconcile the result, switch readers and writers, observe the system, then remove the obsolete component in a later release.

I do not combine “create replacement, migrate all data, cut over every consumer, and delete the old field” into one irreversible window unless the risk is exceptionally well understood. Reports, integrations, formulas, Flow versions, validation rules, permission sets, managed packages, and external exports may still reference the old component.

The destructive step needs explicit approval, dependency evidence, a metadata backup, a data retention decision, and a tested recovery path. A destructiveChanges manifest is an execution mechanism, not a safety assessment.

Strong answer

The runbook names the owner, approver, target org, artifact, start time, maintenance or communication plan, prechecks, exact commands, expected durations, stop conditions, dependencies, data steps, activation sequence, verification queries, monitoring, and recovery actions.

I distinguish four kinds of work:

1. Metadata: objects, code, Flow, UI, permissions, sharing, and deletions.
2. Configuration: environment-specific endpoints, credentials, certificates, feature settings, users, queues, and custom metadata values.
3. Data: backfills, transformations, ownership changes, reconciliation, and retry files.
4. Operations: pausing integrations, notifying users, activating features, warming caches, monitoring jobs, and handing off to support.

Each manual step needs evidence and a second-person check when the risk justifies it. “Admin will configure production afterward” is not a controlled release step.

Strong answer

I minimize the work that must occur in the visible cutover. Validate production beforehand, use quick deploy when eligible, stage backward-compatible metadata, rehearse data scripts, and keep feature activation separate from transport where possible.

A custom permission, custom metadata flag, permission-set assignment, or another governed switch can let the team deploy dormant functionality and enable it for a pilot population after checks. The switch itself must be secure, versioned or documented, tested in both states, and included in recovery.

For long-running sharing recalculations, field-type conversions, test execution, or data migrations, I choose a low-traffic window and communicate expected behavior. I do not disable validation or automation casually; any temporary bypass needs an owner, expiry, audit trail, and explicit re-enable verification.

Strong answer

I triage impact first: which users and transactions fail, whether data integrity or security is at risk, and whether a feature flag, permission correction, configuration repair, or small forward fix is safer than a full metadata reversal.

If the impact is severe or still growing, I stop dependent jobs and integrations, disable the affected feature through the approved control, preserve logs and deployment IDs, and invoke the incident owner. The recovery choice must consider metadata, data, and external side effects separately.

A failed validate-only deployment changes no metadata. A failed deployment may be rolled back by the deployment service depending on its options and state. But after a successful release, “rollback” usually means deploying a tested last-known-good metadata version or a forward fix. That does not automatically undo emails, callouts, data changes, queued jobs, deleted data, or actions completed by external systems.

Strong answer

I verify the deployment record and component counts, then prove the feature with representative personas. I check active Flow and Apex behavior, permission assignments, page and app visibility, sharing, scheduled or asynchronous work, integrations, and key business data.

I run a small set of production-safe smoke tests with known test records, inspect logs and failed jobs, verify alerts, and reconcile any migration counts and totals. Negative tests matter: an unauthorized user must remain blocked, duplicate automation must not run, and an excluded record must stay unchanged.

Finally, I confirm temporary controls were restored, support has the release notes and known-error guidance, dashboards are quiet, and the rollback or forward-fix decision window has an accountable owner. The release closes only when the agreed monitoring period and business acceptance are complete.