Deployment Status
Deployment Status in Salesforce is the legacy Setup page that monitors change-set-based deployments specifically: change sets received from connected orgs and change sets deployed locally.
Definition
Deployment Status in Salesforce is the legacy Setup page that monitors change-set-based deployments specifically: change sets received from connected orgs and change sets deployed locally. The page shows each change set with its status (Pending, Deploying, Deployed, Failed, Validation Only), the components included, the deploying user, and detailed errors for failed deployments. Deployment Status predates the unified Deployment Manager and remains the focused view for change-set deployments.
Deployment Status exists because change sets have specific lifecycle states that benefit from a focused view: Validate (dry-run), Deploy (commit), Quick Deploy (skip tests on previously-validated), Cancel. The page surfaces these state transitions clearly for change set work. Most modern Salesforce orgs use a mix of change sets (admin-led) and source-tracked deploys (developer-led); Deployment Status covers the change set side, Deployment Manager covers everything.
Why Deployment Status remains the focused view for change-set deployment work
Where Deployment Status lives in setup
Setup, Deploy, Deployment Status (or Inbound Change Sets, the related but distinct page that lists change sets received from other orgs). Deployment Status shows the deployment lifecycle for change sets the admin has acted on; Inbound Change Sets shows the change sets awaiting action. Both surfaces are change-set-specific; cross-source deployment visibility lives in Deployment Manager.
The change set deployment lifecycle
Each change set moves through states: Pending (waiting for deploy or validate trigger), Validating (dry-run in progress), Validated (dry-run succeeded; eligible for Quick Deploy), Deploying (actual commit in progress), Deployed (commit succeeded), Failed (validation or deployment failed), Canceled (admin aborted). The state transitions are visible in Deployment Status; admins follow the lifecycle and act at each transition point. The Validated state is the launchpad for Quick Deploy during production windows.
Validate vs Deploy and the safer-rollout pattern
Validate runs the same checks as Deploy (dependency resolution, code compilation, test execution if Apex is included) without committing changes. The validated state proves the deployment will succeed; Quick Deploy commits within the validation expiration window without re-running tests. The pattern: Validate first to catch issues, Quick Deploy to commit when ready. Most production change-set deployments follow Validate-then-Quick-Deploy; skipping Validate produces partial-deploy failures that are harder to roll back.
Per-component results and the failure debugging
Click into a failed deployment for per-component results. Each component shows succeeded or failed with the specific error message. Common failure causes: missing dependency (Validation Rule references a field not in the change set), validation rule conflict (the new field violates an existing validation rule), insufficient Apex test coverage (production deploy requires 75 percent org-wide coverage), Apex compilation error (the new code references a method that does not exist). The per-component detail is the actionable debugging surface.
Quick Deploy expiration and the validation window
Validated change sets are eligible for Quick Deploy for 10 days from validation. After 10 days, the validation expires and Deploy must run the full test cycle again. The expiration window is firm; planned production deploys benefit from validating closer to the deploy window rather than weeks in advance. Long-lead validations that expire produce surprise test-run requirements during the production window.
Cancel and the partial-state risk
Deployments in progress can be canceled. Cancel attempts safe abort but may leave the org in a partial state where some components committed and others did not. The pattern: cancel only when the deployment is clearly going wrong (runaway test execution, wrong target deployment); accept that mid-deployment cancel may require manual cleanup. Most successful deployment ops never cancel; cancel is the emergency button.
Deployment Status vs Deployment Manager
Deployment Status is change-set-focused; it shows the change set lifecycle with change-set-specific actions (Validate, Deploy, Quick Deploy, Cancel). Deployment Manager is source-agnostic; it shows every deployment regardless of source. Modern admin pattern: Deployment Status for change-set work specifically (the focused view with the right actions), Deployment Manager for cross-source visibility and unified diagnostic. The two surfaces coexist; pick the right one per the work at hand.
How to use Deployment Status for change-set operations
The pattern: Validate the change set, monitor through Deployment Status, Quick Deploy during production windows, debug failures through per-component results. The page is operational furniture for change-set work; using it actively prevents many deployment surprises.
- Receive the change set in Inbound Change Sets
Setup, Inbound Change Sets. Confirm the uploaded change set is visible. Click into it to see components.
- Validate the change set first
Click Validate. The dry-run starts; monitor through Deployment Status. Validation typically takes 5 to 30 minutes depending on test count.
- Review validation results
Drill into per-component results. Confirm all components succeeded. Fix any failures in the source org, re-upload, re-validate.
- Quick Deploy within 10 days during the production window
Once validated, Quick Deploy commits without re-running tests. Quick deploys take 1 to 5 minutes typically.
- Monitor the Quick Deploy through Deployment Status
Watch the state transition from Quick Deploying to Deployed. Failed Quick Deploys are rare but surface here when they happen.
- Verify deployed components in the target org
Spot-check critical components (Flows activated correctly, Validation Rules enabled, Permission Sets assigned). Confirmation prevents surprises later.
- Cancel only when the deployment is clearly going wrong
Cancel is the emergency button. Runaway tests, wrong target deploy, panic situations. Accept partial-state cleanup may follow.
Validate dry-runs; Deploy commits. Always Validate first for production.
Skips re-running tests on previously-validated change sets. Saves time during production windows.
Emergency abort for in-progress deployments. May leave partial state.
Drill into failed deployments for actionable error messages.
Spot-check critical components in the target org to confirm deployment behavior.
- Quick Deploy expires 10 days after validation. Long-lead validations require re-validation before deploy.
- Per-component failure details are the actionable surface. The deployment-level summary is too generic for debugging.
- Cancel can leave partial state. Manual cleanup may follow; use cancel only as the emergency button.
- Deployment Status is change-set-specific. Cross-source visibility lives in Deployment Manager.
- Production deploys with Apex require 75 percent org-wide test coverage. Sandbox deploys that worked can fail in production if coverage is borderline.
Trust & references
Cross-checked against the following references.
- Deployment Status referenceSalesforce
- Change Sets referenceSalesforce
Straight from the source - Salesforce's reference material on Deployment Status.
- Change SetsSalesforce Help
- Monitor DeploymentsSalesforce Help
- Outbound Change SetsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the Deployment Status page show?
Q2. When is Deployment Status useful?
Q3. How does Deployment Status complement CI/CD logs?
Discussion
Loading discussion…