How To Find Change Sets In Salesforce: Complete Guide | SalesforceTutorial

Change sets in Salesforce are deployment tools that allow administrators to move metadata components between connected Salesforce orgs. If you need to know how to find change sets in Salesforce, this guide covers the complete process including navigation, troubleshooting common issues, and deployment best practices.

What are Change Sets in Salesforce?

Change sets in Salesforce are deployment packages that transfer metadata components between connected orgs. Unlike the Force.com Migration Tool or IDE, change sets provide a point-and-click interface designed for administrators rather than developers. Change sets use packages in the background but offer enhanced functionality to move code from sandbox to production, sandbox to sandbox, and production to sandbox.

For larger organizations, change sets enable multiple developers to create deployment packages that administrators can review and deploy. This separation allows administrators with broader org knowledge to control the deployment process while maintaining security and governance standards.

How To Find Change Sets In Salesforce

To locate change sets in your Salesforce org, follow these navigation steps:

1. Lightning Experience: Click the App Launcher (9 dots) → Search “Change Sets” → Select “Change Sets” from results
2. Classic Interface: Setup → Deploy → Change Sets
3. Quick Setup Search: Type “Change Sets” in the Quick Find box in Setup

Once you access the Change Sets page, you’ll see two tabs:

• Outbound Change Sets: Change sets you create to send to other orgs
• Inbound Change Sets: Change sets received from other orgs awaiting deployment

Salesforce Change Sets Prerequisites

Before you can create or deploy change sets, administrators must establish deployment connections between orgs:

• Deployment connections cannot be created between arbitrary orgs
• By default, deployment connections exist between all orgs affiliated with a production org (sandboxes)
• Connections are automatically created between each sandbox and between each sandbox and the production org
• A deployment connection alone doesn’t enable change set transfers
• Each org must be authorized to send and receive change sets
• This security layer enforces code promotion paths and prevents accidental metadata overwrites

Outbound Change Set Missing In Developer Org

If you cannot find outbound change sets in your developer org, this is expected behavior. Developer Edition orgs do not support outbound change sets because they lack deployment connections to other orgs. Developer orgs are designed for learning and testing, not for deploying metadata to other environments.

To work with change sets, you need:

• A production org with associated sandboxes
• Trailhead Playground orgs (limited change set functionality)
• Partner Developer Edition orgs (with specific licensing)

Are Change Sets Always Created In A Sandbox

No, change sets are not always created in a sandbox. You can create change sets in any org that supports them:

• Sandbox to Production: Most common deployment path
• Production to Sandbox: For refreshing sandbox environments
• Sandbox to Sandbox: For testing across different sandbox types
• Production to Production: Between connected production orgs (rare)

However, Salesforce best practices recommend creating change sets in sandbox environments first, testing thoroughly, then deploying to production.

Creating and Deploying Change Sets

The change set deployment process involves these steps:

Creating an Outbound Change Set

1. Navigate to Setup → Change Sets → Outbound Change Sets
2. Click “New” to create a new change set
3. Enter a descriptive name and description
4. Add components using “Add” button or “Add Profiles” for profile-related changes
5. Review dependencies and add related components
6. Click “Upload” to send to the target org

Deploying an Inbound Change Set

1. In the target org, go to Setup → Change Sets → Inbound Change Sets
2. Locate your change set in the list
3. Click “Deploy” and select deployment options
4. Choose “Check Only” for validation or “Deploy” for actual deployment
5. Monitor deployment status and review results

Change Set Limitations and Considerations

Understanding change set limitations helps avoid deployment issues:

• Size Limit: 39MB maximum per change set
• Component Limit: 10,000 components maximum
• Metadata Coverage: Not all metadata types are supported
• Dependencies: Manual dependency management required
• Rollback: No automatic rollback after successful deployment
• Data: Change sets deploy metadata only, not data records

Troubleshooting Common Change Set Issues

Change Set Not Visible

• Verify deployment connections are established
• Check user permissions for change set access
• Confirm org supports change set functionality
• Ensure change set was uploaded successfully

Deployment Failures

• Review deployment error messages carefully
• Check for missing dependencies
• Verify target org has sufficient storage and limits
• Ensure no conflicting customizations exist

Best Practices for Change Sets

• Naming Convention: Use descriptive names with dates or release numbers
• Documentation: Include detailed descriptions of changes
• Testing: Always test in sandbox before production deployment
• Dependencies: Include all related components and dependencies
• Validation: Use “Check Only” deployment to validate before actual deployment
• Timing: Deploy during maintenance windows to minimize user impact

Alternative Deployment Methods

While change sets work well for many scenarios, consider these alternatives:

• Salesforce CLI: Command-line interface for developers
• VS Code with Salesforce Extensions: Modern development workflow
• Third-party Tools: Gearset, Copado, or AutoRABIT for advanced deployments
• Unlocked Packages: For reusable components across orgs

Frequently Asked Questions