Deployment Settings
Deployment Settings is the Setup page where you authorize change set traffic between related Salesforce orgs.
Definition
Deployment Settings is the Setup page where you authorize change set traffic between related Salesforce orgs. Each connection is one-way unless explicitly enabled in both directions, and both sides have to flip the switch before any change set can move. This is what permits a sandbox to upload an outbound change set to production, or production to upload a change set down to a sandbox.
The page lists every org related to yours (production and its sandboxes, or a sandbox and its peers). For each, you toggle Allow Inbound Changes, which determines whether you accept change sets sent to you. The other org separately toggles Allow Outbound Changes to send. Without both, no change set traffic flows. Deployment Settings has no effect on Salesforce CLI or Metadata API deployments, which authenticate per-user rather than per-org.
How Deployment Settings governs change-set flow
The connection model and what related orgs means
Salesforce considers two orgs related if they share a production parent. Production and its sandboxes are related. Two sandboxes from the same production are related. Two unrelated production orgs or sandboxes from different productions are not related, and you cannot create a connection between them. Deployment Settings shows only related orgs in its list; if you do not see the org you expect, check the parent production.
Inbound versus outbound trust
Each connection has two switches: Allow Inbound Changes (this org will accept change sets sent to it) and Allow Outbound Changes (this org may send change sets to the connected org). Both must be on in their respective orgs for change set traffic to flow. The typical setup is bidirectional between production and a UAT sandbox, but unidirectional from a dev sandbox up to a UAT (dev sends, UAT receives; UAT does not deploy down to dev).
Where Deployment Settings sits in the Setup tree
Setup, then Quick Find, then Deployment Settings. The page lists each related org with an Edit link to toggle the connection switches. Below it (or as a separate Quick Find entry depending on edition) is Deployment Status, which shows the history of inbound and outbound change sets. Together they form the Change Set deployment surface.
What Deployment Settings does not control
Deployment Settings governs Change Sets only. Salesforce CLI deployments (sf project deploy), Metadata API calls from custom tooling, and third-party DevOps platforms authenticate per-user with OAuth and have nothing to do with this page. If you migrate from Change Sets to the CLI, Deployment Settings becomes irrelevant; the CLI uses the developer's credentials and the target org's API permissions.
Sandbox refresh and connection state
When you refresh a sandbox from production, the new sandbox inherits Deployment Settings from the old one only partially. Inbound and outbound flags carry over for the connections that still exist, but you usually have to re-add or re-confirm trust after a refresh. Audit Deployment Settings as part of your post-refresh checklist.
Permissions needed to edit Deployment Settings
Modifying Deployment Settings requires the Modify All Data permission or the Deploy Change Sets permission. Most admins have one or both. View-only access is more permissive, so a developer can usually see the current state without being able to change it. Production deploys often require coordination across an admin, a developer, and a release manager; only the admin can change the trust state.
Outbound quota and the change-set size cap
There is no hard limit on the number of change set connections, but the platform enforces a maximum size per change set and a 10,000-component ceiling. Hitting either limit forces you to split into multiple change sets. Large refactors often produce change sets that exceed the limit and must be broken up by component type or feature. The CLI handles this better, which is one reason teams move away from Change Sets at scale.
How to enable a change set connection between two orgs
Change sets only move between orgs that have explicit trust. Setting up a connection is a five-minute task across both orgs, but it is a coordinated five minutes: one admin alone cannot do it.
- Identify the two orgs
Confirm both orgs are related (same production parent). Sandbox names are visible in Setup, then Sandboxes. If the orgs are not related, you cannot use Change Sets; use Salesforce CLI or a DevOps platform instead.
- Open Deployment Settings in the source org
In the source org (the one sending changes), navigate to Setup, then Quick Find, then Deployment Settings. The page lists related orgs.
- Edit the target org''s connection
Click Edit next to the target org. Check Allow Outbound Changes. Save. The source org is now willing to send change sets to the target.
- Open Deployment Settings in the target org
Switch to the target org. Same path: Setup, then Deployment Settings. Find the source org in the list.
- Enable inbound on the target
Click Edit next to the source org. Check Allow Inbound Changes. Save. The target org now accepts change sets from the source.
- Test with a small change set
In the source org, create a small outbound change set with one or two components. Upload it. Switch to the target and confirm it appears in Inbound Change Sets. Deploy as a smoke test before relying on the connection for real work.
The receiving org''s switch. When on, the org accepts change sets uploaded by orgs with outbound permission.
The sending org''s switch. When on, the org may upload change sets to the listed connected org.
Both switches on in both orgs, allowing change sets to flow either direction. Common between production and UAT.
Switches on only in one direction. Common between dev sandboxes and an upstream UAT.
- Both switches must be on for traffic to flow. A common mistake is enabling outbound in the source without confirming inbound in the target. The change set uploads but never appears in the receiving org.
- Deployment Settings has no effect on CLI or Metadata API deploys. If your team is on Salesforce DX, this page can be ignored entirely.
- A sandbox refresh can break existing connections. Re-audit Deployment Settings after any refresh, especially in production environments where downtime in the deploy pipeline is expensive.
- Production-to-production deployments require both production orgs to share a parent, which is rare. For unrelated production orgs, Change Sets are not an option; you must use the CLI, Metadata API, or a DevOps platform.
Trust & references
Straight from the source - Salesforce's reference material on Deployment Settings.
- Authorize a Deployment ConnectionSalesforce Help
- About 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 is required before deploying Deployment Settings-related code to production?
Q2. Where would a developer typically work with Deployment Settings?
Q3. What is a Governor Limit in the context of Deployment Settings?
Discussion
Loading discussion…