What Change Sets Do Not Move

Why This Topic Matters

Change sets are the most common point-and-click deployment tool in Salesforce, and they appear frequently in the Environment Management and Deployment section of the Advanced Administrator exam. However, a significant portion of exam questions on change sets are not about what they can move but about what they cannot move. Understanding these limitations is critical because a deployment that looks complete in a sandbox can fail or behave unexpectedly in production if an administrator assumes change sets carry over everything. In real-world work, knowing these gaps prevents broken integrations, missing data, and misconfigured security after go-live. On the exam, these gaps are tested through scenario questions where you must identify why something did not appear in the target org or what additional manual steps are required after deployment.

What Change Sets Are

A change set is a collection of metadata components that can be sent from one Salesforce org to another connected org, typically from a sandbox to production or between sandboxes that share the same production org. An outbound change set is created in the source org and uploaded; an inbound change set is received in the target org, where it can be validated and deployed. Change sets rely on a deployment connection between orgs, which must be authorized in the target org before anything can be received.

The key word is metadata. Change sets move configuration, not records. They also move only a defined set of component types, and even some metadata types are either not supported at all or are only partially supported.

What Change Sets Do Not Move

The following categories are the ones most often tested and most often misunderstood:

1. Data and Records
Change sets never move data. This includes account, contact, opportunity, custom object records, attachments, files, Chatter posts, and any other record-level information. If a sandbox was populated with test data or if a partial copy or full sandbox contains production data, none of it travels in a change set. Data must be moved using Data Loader, Data Import Wizard, or third-party tools.

2. Unsupported Metadata Types
Several configuration items cannot be included in a change set at all. Commonly cited examples include:
- Account Teams and Opportunity Team settings
- Case Team Roles and other case team configuration
- Lead and Case assignment rule activation state (rules themselves may deploy, but the active flag behavior is nuanced)
- Auto-number field starting values
- Multi-currency settings and currency conversion rates
- Fiscal year settings
- Organization-Wide Default sharing settings for standard objects
- Public Groups membership (the group structure may move but members do not)
- Queue membership
- Support settings, support processes in some cases, and various org-level settings such as Lead Settings and Opportunity Settings
- Email deliverability and email-to-case routing addresses
- Web-to-Lead and Web-to-Case HTML forms
- Mail merge templates
- Letterheads in some older contexts
- Divisions
- Territory management rules in some configurations
- Some types of Salesforce Knowledge configuration
- Standard picklist values in certain situations

3. Users and User-Related Assignments
User records do not move. Because of this, anything tied to specific users does not move either: profile assignments to users, permission set assignments, role assignments to users, group memberships, queue memberships, and public group members. You can deploy a permission set, but you must assign it to users in the target org manually or via Data Loader.

4. Profiles and Permission Sets: Only Partial Movement
Profiles and permission sets can be added to a change set, but they only carry permissions related to the other components in the same change set. For example, if you add a profile and a new custom object, the object permissions and field-level security for that object are included. If the profile is added without related components, very little of its permission configuration is deployed. Login IP ranges and login hours on profiles are a common exception and are deployed only when the profile is explicitly added, which is why exam questions frequently test whether field-level security came across with a field.

5. Component Dependencies Are Not Automatic
A change set does not automatically include dependent components. If you add a custom field but not the custom object it belongs to, and the object does not yet exist in the target org, the deployment fails. The View/Add Dependencies button helps identify these, but the administrator must explicitly include them. This is tested as a scenario where a deployment fails or a component is missing.

6. Deletions
Change sets cannot delete anything in the target org. If you delete a field in a sandbox, deploying a change set will not remove that field from production. Destructive changes require Metadata API tools such as Salesforce CLI, Workbench, or the Ant Migration Tool, or a manual deletion in the target org.

7. Activation States and Some Settings
Flows deploy as inactive by default unless a specific setting allows active deployment. Validation rules and workflow rules deploy with their active state, but approval processes require that related fields and email templates exist. Scheduled jobs, scheduled reports, and scheduled dashboards do not move. Apex jobs that are scheduled must be rescheduled in the target org.

8. Connected Apps Secrets, Named Credential Passwords, and Authentication Details
Named Credentials, Remote Site Settings, and Connected Apps can be deployed as metadata, but passwords, consumer secrets, certificates, and OAuth tokens are not transferred. These must be re-entered in the target org after deployment.

9. Org-Specific Settings
Company information, business hours in some cases, holidays, email footers, Chatter settings, and many items under Setup that are considered org-wide settings are not deployable via change sets.

10. Reports and Dashboards: Folder and Access Limits
Reports and dashboards can move, but they must be in a public or shared folder that is also included in the change set. Private reports and dashboards cannot be deployed. The running user of a dashboard must exist in the target org or deployment fails.

How It Works in Practice

The recommended approach is to treat a change set as the core of a deployment, not the whole deployment. A complete deployment plan typically includes:
- Pre-deployment steps: manually create items that change sets cannot move but that other components depend on, such as queue membership, certain settings, or multi-currency setup.
- The change set itself: validate first, then deploy.
- Post-deployment steps: activate flows, assign permission sets to users, enter credentials, reschedule jobs, load data, set OWDs for standard objects, add users to groups and queues, and recreate any unsupported configuration manually.

Documenting these manual steps in a deployment checklist is considered best practice and is often the correct answer in exam scenarios that ask how an administrator should ensure a complete migration.

Alternatives When Change Sets Fall Short

The exam expects you to know when to recommend another tool:
- Data Loader for records.
- Metadata API tools such as Salesforce CLI, Workbench, Visual Studio Code with Salesforce Extensions, or the Ant Migration Tool for destructive changes, broader metadata coverage, and automation.
- DevOps Center for source-driven deployments with change tracking.
- Unmanaged or managed packages when moving components between unrelated orgs that do not share a production org.
- Manual configuration for org settings and unsupported types.

How to Answer Exam Questions on This Topic

Questions typically follow a pattern: a deployment was performed, something is missing or broken in production, and you must identify the cause or the next step. Work through the scenario by asking:

1. Is the missing item data? If yes, change sets never move it. Look for Data Loader as the answer.
2. Is the missing item tied to a user? Permission set assignments, group members, queue members, and role assignments must be done in the target org.
3. Is it a profile or permission set permission? Check whether the related component was in the same change set. If not, the permissions did not come over.
4. Is it a deletion? Change sets cannot delete; the answer involves Metadata API or manual removal.
5. Is it an activation state? Flows deploy inactive; jobs must be rescheduled.
6. Is it a secret or credential? These are never transferred for security reasons.
7. Is it an org-level setting or a type on the unsupported list? The answer is manual configuration.
8. Is a dependency missing? The deployment likely failed because a required component was not included.

Exam Tips: Answering Questions on What Change Sets Do Not Move

- Remember the core rule: change sets move metadata, never data. Any answer suggesting records moved via a change set is wrong.
- Watch for user-dependent items. If the question mentions users not having access after deployment, the answer almost always involves manual assignment of permission sets, profiles, roles, or group and queue membership.
- Profiles are partial. If a question says field-level security did not deploy, check whether the field and the profile were both in the change set. The correct answer usually requires adding both together or setting FLS manually.
- Change sets cannot delete. If the scenario involves removing a field, object, or component from production, the answer is Metadata API, Salesforce CLI, Workbench, or manual deletion, not a change set.
- Flows arrive inactive. If a question says automation is not running after deployment, activation in the target org is the likely fix.
- Credentials never move. Named Credentials, Connected App secrets, and certificates must be re-entered.
- Scheduled items do not move. Scheduled Apex, scheduled reports, and dashboard refresh schedules must be recreated.
- Dependencies are manual. If a deployment fails with a missing component error, the answer is to include the dependent components, often identified through View/Add Dependencies.
- Org-wide settings are manual. Standard object OWDs, multi-currency, fiscal year, and most Setup-level settings must be configured directly in the target org.
- Recognize when to recommend another tool. If the question involves orgs that are not connected, use packages. If it involves automation or destructive changes, use Metadata API tools. If it involves data, use Data Loader.
- Favor answers that include a documented pre- and post-deployment checklist when the question asks about best practice for ensuring a complete migration.
- Eliminate absolute answers. Options claiming a change set will move everything or that no manual steps are needed are almost always incorrect.

Summary

Change sets are powerful for moving supported metadata between connected orgs, but they do not move data, users, user assignments, deletions, credentials, scheduled jobs, many org-level settings, or dependent components unless explicitly added. Profiles and permission sets move only partially, and flows deploy inactive. On the exam, identify the category of the missing or broken item, match it to the known limitation, and choose the answer that completes the deployment through manual steps, Data Loader, or Metadata API tools. Mastering these limitations is what separates a basic understanding of change sets from the advanced-level knowledge the certification expects.