Change Set Components and Dependencies
5 minutes
5 Questions
Change Sets are the declarative tool Salesforce provides for migrating metadata between connected orgs, such as moving customizations from a sandbox to production. For the Platform Administrator II exam, understanding components and dependencies is essential because incomplete change sets are a leading cause of failed deployments. Components are the individual metadata items you add to a change set, such as custom objects, custom fields, Apex classes, Visualforce pages, validation rules, workflow rules, flows, page layouts, record types, permission sets, profiles, custom tabs, apps, reports, dashboards, email templates, and Lightning components. Not everything is deployable; data records, some org-wide settings, and certain items like standard picklist values or Lead Assignment Rule order are not supported and must be configured manually in the target org. Dependencies are the related components that a selected component requires to function. For example, a custom field depends on its parent object; a page layout depends on the fields, record types, and custom buttons it references; an Apex class may depend on other classes, custom objects, or custom settings; a report depends on a custom report type. Salesforce offers a 'View/Add Dependencies' button on the outbound change set, which scans your selected components and suggests related items. However, this detection is not exhaustive, so administrators must carefully review and manually add anything missed. Key considerations include: profiles and permission sets only carry permissions for components included in the same change set; a deployment connection must be established between orgs with inbound and outbound authorization; change sets are validated in the target org, and any missing dependency causes the entire deployment to fail atomically. Best practices are to validate before deploying, use a consistent naming convention, document components, deploy in logical order (objects and fields first, then automation and layouts), and run Apex tests to meet the 75 percent coverage requirement for production.
Change Set Components and Dependencies: The Complete Guide for the Salesforce Advanced Administrator Exam
Why This Topic Matters
Change sets are the native, point-and-click tool for moving customizations between related Salesforce environments (for example, from a sandbox to production). On the Advanced Administrator exam, the Environment Management and Deployment section tests whether you understand not just how to click through a change set, but why deployments fail, which components can and cannot travel in a change set, and how dependencies between components must be managed. In real life, a missed dependency is the single most common reason a deployment errors out at the worst possible moment. Expect scenario questions that describe a failed deployment or a planning situation and ask you to identify the cause or the best approach.
What Is a Change Set?
A change set is a collection of metadata components (configuration, not data) that you package in a source org and send to a related target org. Key facts:
• Outbound change set: Created in the source org (where the changes were built). You select components, optionally add dependencies, and upload it to a target.
• Inbound change set: Received in the target org. You can Validate it or Deploy it.
• Change sets only work between orgs that are related (a production org and its sandboxes, or sandboxes created from the same production org). You cannot send a change set to an unrelated org; for that you need unmanaged packages, Metadata API tools, Salesforce CLI, or DevOps Center.
• Change sets move metadata only; they never move records (data). Use Data Loader, Data Import Wizard, or sandbox templates for data.
• A change set is additive: it can create or update components in the target, but it cannot delete components, rename them, or change certain attributes (such as converting a field's data type). Deletions must be performed manually in the target org.
Deployment Connections
Before any change set can be sent, a deployment connection must exist and inbound changes must be allowed. Go to Setup > Deployment Settings in the target (receiving) org and select Allow Inbound Changes from the source org. Remember this exam-favorite detail: the permission is granted in the receiving org, not the sending one. Deployment connections are created automatically between related orgs, but inbound changes are disabled by default. If a question says 'the sandbox does not appear as an available target,' the answer almost always involves deployment settings or the orgs not being related.
Components: What Can Be Included
Most commonly used metadata is supported, including: custom objects and custom fields, custom tabs and apps, page layouts, record types, validation rules, Apex classes and triggers, Visualforce pages and components, Lightning web components and Aura components, Lightning pages (FlexiPages), flows and processes, workflow rules, email templates and letterheads, email alerts, field updates, approval processes, assignment and escalation rules, custom labels, custom settings and custom metadata types (definitions, and custom metadata records), reports, dashboards, report types, list views, global picklist value sets, permission sets, permission set groups, profiles, custom permissions, sharing rules, queues, public groups, roles, remote site settings, named credentials, static resources, and more.
Components: What Cannot Be Included
The exam frequently tests awareness that not everything is deployable. Many org-level settings must be configured manually in the target org. Commonly cited unsupported or partially supported items include: organization-wide default sharing settings for standard objects, standard picklist values, account team and opportunity team settings, activity settings, case and lead settings, currency and multi-currency setup, fiscal year settings, email deliverability settings, company information, user records, and most data. If a scenario describes a setting that was configured in a sandbox and asks how to get it to production and the setting is an org-wide configuration, the correct answer is typically 'configure it manually in production' rather than 'add it to the change set.'
Understanding Dependencies
A dependency is a component that another component relies on to function or even to exist. Examples:
• A custom field depends on its parent custom object.
• A page layout depends on every field, related list object, button, and quick action it references.
• A validation rule or formula field depends on every field it references.
• An Apex class may depend on other Apex classes, custom objects, custom fields, custom labels, and custom settings.
• A record type depends on its object and the picklist values it assigns.
• A flow depends on the objects, fields, Apex actions, and email templates it references.
• A permission set or profile depends on the objects, fields, tabs, apps, and Apex classes it grants access to.
• A report depends on its report type and the fields it displays and filters on.
If the target org does not already contain a required dependency and the change set does not include it, the deployment fails with errors such as 'no CustomField named Account.Region__c found' or 'Entity not found.' The target must have every referenced component either already present or included in the same change set.
View/Add Dependencies
On the outbound change set page, after adding components, click View/Add Dependencies. Salesforce scans the selected components and lists other components they depend on, which you can then select and add. Important nuances the exam loves:
• The dependency check is helpful but not exhaustive. It detects structural metadata relationships but does not catch everything (for example, hard-coded references inside Apex or formula logic, or layouts that reference components in ways the scanner cannot resolve). You remain responsible for a complete change set.
• Dependencies are not added automatically; you must explicitly select them after viewing.
• Adding a parent object does not automatically include all of its fields, layouts, or record types. You add each component type deliberately.
Profiles and Permission Sets in Change Sets
This is a classic exam trap. When you add a profile to a change set, the profile component carries permissions only for the other components that are also in the same change set (object permissions, field-level security, Apex class and Visualforce page access, tab visibility, app visibility, record type assignments for the included items), plus certain profile-level settings. It does not export the entire profile. So if you want field-level security for a new field to deploy, add both the field and the relevant profiles (or permission sets) to the same change set. Permission sets, by contrast, are deployed with their full contents, which is one reason permission sets are often the recommended security model for deployments. Also note that you cannot create a brand-new profile in the target via change set unless it is being deployed along with components; standard profiles exist in all orgs, and custom profiles must already exist or be created by the deployment.
Flows, Processes, and Automation
Flows and processes are deployed as inactive by default. After deployment you must activate the new version manually in the target. The exception: if the target org has the setting Deploy processes and flows as active enabled (in Process Automation Settings), flows deploy active, but the deployment must then meet flow test coverage requirements. Workflow rules, approval processes, and validation rules deploy in the active or inactive state they held in the source. Approval processes have strict dependencies on queues, email templates, and fields used in entry criteria, so missing any of these causes failure.
Apex Testing and Deployment to Production
When the target is a production org and the change set contains Apex, the deployment runs tests and requires at least 75 percent code coverage overall, with all tests passing and every trigger having some coverage. Test options when deploying or validating an inbound change set are Default (runs local tests only if Apex is included), Run Local Tests (excludes managed package tests), Run All Tests, and Run Specified Tests. Deployments to sandboxes do not require coverage unless you choose to run tests.
Validate and Quick Deploy
You can Validate an inbound change set, which runs the full deployment check (including Apex tests) without committing any changes. This is a best practice to catch missing dependencies before a production window. If the validation succeeds (including test runs), you can use Quick Deploy from Deployment Status within 10 days to deploy without rerunning tests, dramatically shortening the production deployment window.
Lifecycle Details and Limits
• Once a change set is uploaded, it becomes locked and cannot be edited. To make changes, clone it, adjust the clone, and upload the clone.
• An uploaded change set may take up to about 30 minutes to appear in the target org's inbound list.
• A change set can contain up to 10,000 files, and the total size cannot exceed 400 MB.
• Change sets are deployed as a single transaction: if any component fails, the whole deployment is rolled back (unless partial save is used via the Metadata API, which change sets do not expose).
• Deployment Status in Setup shows the result and error details for every component.
• A single change set deploys to one target org; to send the same changes to multiple sandboxes, upload the change set to each target or clone it.
Best Practices for Dependency Management
1. Build a deployment checklist as you develop: record every new object, field, layout, class, flow, and security change.
2. Add components by type systematically (objects first, then fields, then layouts, record types, automation, security).
3. Always click View/Add Dependencies, then review manually for references the scanner may miss.
4. Include permission sets or profiles alongside new fields and objects so access is granted on deployment.
5. Validate in the target before the real deployment window; fix errors; then use Quick Deploy.
6. Document manual post-deployment steps: activating flows, setting org-wide defaults, adding standard picklist values, assigning permission sets to users, configuring unsupported settings.
7. When dependencies are large or orgs are unrelated, consider packages, Salesforce CLI, or DevOps Center instead.
Exam Tips: Answering Questions on Change Set Components and Dependencies
• Read for the failure clue. If a question says a deployment failed with an error about a field or object that 'could not be found,' the answer is a missing dependency: add the referenced component to the change set (or confirm it exists in the target).
• Related orgs only. Any question about deploying to a developer edition org, a partner's org, or an unrelated production org rules out change sets. Choose packages, Metadata API/CLI, or DevOps Center.
• Receiving org controls permission. If change sets cannot be sent, check Deployment Settings in the target org and ensure Allow Inbound Changes is selected.
• Profiles carry only what travels with them. When the scenario says 'field-level security was not deployed,' the correct fix is to include the profile or permission set and the field in the same change set, or to prefer permission sets.
• Flows arrive inactive. If users report automation is not running after a flow deployment, the admin must activate the flow in the target (or the org has not enabled deploying flows as active).
• Change sets never delete. Any question asking how to remove a field or component in production via change set is a distractor; the answer is manual deletion in the target.
• Uploaded means locked. To modify an uploaded change set, clone it.
• Org-wide settings are manual. Sharing defaults for standard objects, standard picklist values, currency, fiscal year, and similar settings must be configured directly in the target.
• 75 percent coverage for production. Production deployments containing Apex require tests to pass and coverage of 75 percent; sandbox deployments do not.
• Validate first, Quick Deploy later. When a question emphasizes minimizing downtime or risk during a production release, the best answer is to validate ahead of time and use Quick Deploy within the validation window.
• View/Add Dependencies is a helper, not a guarantee. If an answer choice claims the dependency tool automatically includes everything needed, it is wrong.
• Metadata, not data. Any option suggesting records move with a change set is incorrect.
Sample Question Walkthrough
Scenario: An administrator creates a new custom object with five fields, a page layout, a record type, and a permission set in a Full sandbox. The change set is deployed to production but fails with an error stating that a field referenced by the page layout cannot be found.
Analysis: The page layout depends on every field it displays. The error indicates at least one field is missing from the change set. The best answer is to use View/Add Dependencies on the outbound change set, add the missing field(s), clone the locked change set if it was already uploaded, upload again, validate, and deploy. Distractor answers such as 'delete the layout in production,' 'load the data with Data Loader,' or 'change the deployment connection' do not address the dependency problem.
Summary
Change sets are simple on the surface, but exam success depends on mastering the details: related orgs and deployment connections, supported versus unsupported components, explicit dependency management, how profiles and permission sets behave, inactive flows, Apex coverage rules, validation and Quick Deploy, and the fact that change sets are additive and locked after upload. If you can diagnose a failed deployment by identifying its missing or unsupported component, you are ready for this section of the Advanced Administrator exam.
Change sets are the native, point-and-click tool for moving customizations between related Salesforce environments (for example, from a sandbox to production). On the Advanced Administrator exam, the Environment Management and Deployment section tests whether you understand not just how to click through a change set, but why deployments fail, which components can and cannot travel in a change set, and how dependencies between components must be managed. In real life, a missed dependency is the single most common reason a deployment errors out at the worst possible moment. Expect scenario questions that describe a failed deployment or a planning situation and ask you to identify the cause or the best approach.
What Is a Change Set?
A change set is a collection of metadata components (configuration, not data) that you package in a source org and send to a related target org. Key facts:
• Outbound change set: Created in the source org (where the changes were built). You select components, optionally add dependencies, and upload it to a target.
• Inbound change set: Received in the target org. You can Validate it or Deploy it.
• Change sets only work between orgs that are related (a production org and its sandboxes, or sandboxes created from the same production org). You cannot send a change set to an unrelated org; for that you need unmanaged packages, Metadata API tools, Salesforce CLI, or DevOps Center.
• Change sets move metadata only; they never move records (data). Use Data Loader, Data Import Wizard, or sandbox templates for data.
• A change set is additive: it can create or update components in the target, but it cannot delete components, rename them, or change certain attributes (such as converting a field's data type). Deletions must be performed manually in the target org.
Deployment Connections
Before any change set can be sent, a deployment connection must exist and inbound changes must be allowed. Go to Setup > Deployment Settings in the target (receiving) org and select Allow Inbound Changes from the source org. Remember this exam-favorite detail: the permission is granted in the receiving org, not the sending one. Deployment connections are created automatically between related orgs, but inbound changes are disabled by default. If a question says 'the sandbox does not appear as an available target,' the answer almost always involves deployment settings or the orgs not being related.
Components: What Can Be Included
Most commonly used metadata is supported, including: custom objects and custom fields, custom tabs and apps, page layouts, record types, validation rules, Apex classes and triggers, Visualforce pages and components, Lightning web components and Aura components, Lightning pages (FlexiPages), flows and processes, workflow rules, email templates and letterheads, email alerts, field updates, approval processes, assignment and escalation rules, custom labels, custom settings and custom metadata types (definitions, and custom metadata records), reports, dashboards, report types, list views, global picklist value sets, permission sets, permission set groups, profiles, custom permissions, sharing rules, queues, public groups, roles, remote site settings, named credentials, static resources, and more.
Components: What Cannot Be Included
The exam frequently tests awareness that not everything is deployable. Many org-level settings must be configured manually in the target org. Commonly cited unsupported or partially supported items include: organization-wide default sharing settings for standard objects, standard picklist values, account team and opportunity team settings, activity settings, case and lead settings, currency and multi-currency setup, fiscal year settings, email deliverability settings, company information, user records, and most data. If a scenario describes a setting that was configured in a sandbox and asks how to get it to production and the setting is an org-wide configuration, the correct answer is typically 'configure it manually in production' rather than 'add it to the change set.'
Understanding Dependencies
A dependency is a component that another component relies on to function or even to exist. Examples:
• A custom field depends on its parent custom object.
• A page layout depends on every field, related list object, button, and quick action it references.
• A validation rule or formula field depends on every field it references.
• An Apex class may depend on other Apex classes, custom objects, custom fields, custom labels, and custom settings.
• A record type depends on its object and the picklist values it assigns.
• A flow depends on the objects, fields, Apex actions, and email templates it references.
• A permission set or profile depends on the objects, fields, tabs, apps, and Apex classes it grants access to.
• A report depends on its report type and the fields it displays and filters on.
If the target org does not already contain a required dependency and the change set does not include it, the deployment fails with errors such as 'no CustomField named Account.Region__c found' or 'Entity not found.' The target must have every referenced component either already present or included in the same change set.
View/Add Dependencies
On the outbound change set page, after adding components, click View/Add Dependencies. Salesforce scans the selected components and lists other components they depend on, which you can then select and add. Important nuances the exam loves:
• The dependency check is helpful but not exhaustive. It detects structural metadata relationships but does not catch everything (for example, hard-coded references inside Apex or formula logic, or layouts that reference components in ways the scanner cannot resolve). You remain responsible for a complete change set.
• Dependencies are not added automatically; you must explicitly select them after viewing.
• Adding a parent object does not automatically include all of its fields, layouts, or record types. You add each component type deliberately.
Profiles and Permission Sets in Change Sets
This is a classic exam trap. When you add a profile to a change set, the profile component carries permissions only for the other components that are also in the same change set (object permissions, field-level security, Apex class and Visualforce page access, tab visibility, app visibility, record type assignments for the included items), plus certain profile-level settings. It does not export the entire profile. So if you want field-level security for a new field to deploy, add both the field and the relevant profiles (or permission sets) to the same change set. Permission sets, by contrast, are deployed with their full contents, which is one reason permission sets are often the recommended security model for deployments. Also note that you cannot create a brand-new profile in the target via change set unless it is being deployed along with components; standard profiles exist in all orgs, and custom profiles must already exist or be created by the deployment.
Flows, Processes, and Automation
Flows and processes are deployed as inactive by default. After deployment you must activate the new version manually in the target. The exception: if the target org has the setting Deploy processes and flows as active enabled (in Process Automation Settings), flows deploy active, but the deployment must then meet flow test coverage requirements. Workflow rules, approval processes, and validation rules deploy in the active or inactive state they held in the source. Approval processes have strict dependencies on queues, email templates, and fields used in entry criteria, so missing any of these causes failure.
Apex Testing and Deployment to Production
When the target is a production org and the change set contains Apex, the deployment runs tests and requires at least 75 percent code coverage overall, with all tests passing and every trigger having some coverage. Test options when deploying or validating an inbound change set are Default (runs local tests only if Apex is included), Run Local Tests (excludes managed package tests), Run All Tests, and Run Specified Tests. Deployments to sandboxes do not require coverage unless you choose to run tests.
Validate and Quick Deploy
You can Validate an inbound change set, which runs the full deployment check (including Apex tests) without committing any changes. This is a best practice to catch missing dependencies before a production window. If the validation succeeds (including test runs), you can use Quick Deploy from Deployment Status within 10 days to deploy without rerunning tests, dramatically shortening the production deployment window.
Lifecycle Details and Limits
• Once a change set is uploaded, it becomes locked and cannot be edited. To make changes, clone it, adjust the clone, and upload the clone.
• An uploaded change set may take up to about 30 minutes to appear in the target org's inbound list.
• A change set can contain up to 10,000 files, and the total size cannot exceed 400 MB.
• Change sets are deployed as a single transaction: if any component fails, the whole deployment is rolled back (unless partial save is used via the Metadata API, which change sets do not expose).
• Deployment Status in Setup shows the result and error details for every component.
• A single change set deploys to one target org; to send the same changes to multiple sandboxes, upload the change set to each target or clone it.
Best Practices for Dependency Management
1. Build a deployment checklist as you develop: record every new object, field, layout, class, flow, and security change.
2. Add components by type systematically (objects first, then fields, then layouts, record types, automation, security).
3. Always click View/Add Dependencies, then review manually for references the scanner may miss.
4. Include permission sets or profiles alongside new fields and objects so access is granted on deployment.
5. Validate in the target before the real deployment window; fix errors; then use Quick Deploy.
6. Document manual post-deployment steps: activating flows, setting org-wide defaults, adding standard picklist values, assigning permission sets to users, configuring unsupported settings.
7. When dependencies are large or orgs are unrelated, consider packages, Salesforce CLI, or DevOps Center instead.
Exam Tips: Answering Questions on Change Set Components and Dependencies
• Read for the failure clue. If a question says a deployment failed with an error about a field or object that 'could not be found,' the answer is a missing dependency: add the referenced component to the change set (or confirm it exists in the target).
• Related orgs only. Any question about deploying to a developer edition org, a partner's org, or an unrelated production org rules out change sets. Choose packages, Metadata API/CLI, or DevOps Center.
• Receiving org controls permission. If change sets cannot be sent, check Deployment Settings in the target org and ensure Allow Inbound Changes is selected.
• Profiles carry only what travels with them. When the scenario says 'field-level security was not deployed,' the correct fix is to include the profile or permission set and the field in the same change set, or to prefer permission sets.
• Flows arrive inactive. If users report automation is not running after a flow deployment, the admin must activate the flow in the target (or the org has not enabled deploying flows as active).
• Change sets never delete. Any question asking how to remove a field or component in production via change set is a distractor; the answer is manual deletion in the target.
• Uploaded means locked. To modify an uploaded change set, clone it.
• Org-wide settings are manual. Sharing defaults for standard objects, standard picklist values, currency, fiscal year, and similar settings must be configured directly in the target.
• 75 percent coverage for production. Production deployments containing Apex require tests to pass and coverage of 75 percent; sandbox deployments do not.
• Validate first, Quick Deploy later. When a question emphasizes minimizing downtime or risk during a production release, the best answer is to validate ahead of time and use Quick Deploy within the validation window.
• View/Add Dependencies is a helper, not a guarantee. If an answer choice claims the dependency tool automatically includes everything needed, it is wrong.
• Metadata, not data. Any option suggesting records move with a change set is incorrect.
Sample Question Walkthrough
Scenario: An administrator creates a new custom object with five fields, a page layout, a record type, and a permission set in a Full sandbox. The change set is deployed to production but fails with an error stating that a field referenced by the page layout cannot be found.
Analysis: The page layout depends on every field it displays. The error indicates at least one field is missing from the change set. The best answer is to use View/Add Dependencies on the outbound change set, add the missing field(s), clone the locked change set if it was already uploaded, upload again, validate, and deploy. Distractor answers such as 'delete the layout in production,' 'load the data with Data Loader,' or 'change the deployment connection' do not address the dependency problem.
Summary
Change sets are simple on the surface, but exam success depends on mastering the details: related orgs and deployment connections, supported versus unsupported components, explicit dependency management, how profiles and permission sets behave, inactive flows, Apex coverage rules, validation and Quick Deploy, and the fact that change sets are additive and locked after upload. If you can diagnose a failed deployment by identifying its missing or unsupported component, you are ready for this section of the Advanced Administrator exam.
Test mode:
Admin II - Change Set Components and Dependencies Example Questions
Test your knowledge of Change Set Components and Dependencies
Question 1
In a sandbox, an administrator at Ursa Major Solar built a custom object with several custom fields and a record-triggered flow. The flow references a new custom label and an Account field that already exists in production. In the same release, two obsolete custom fields on Case were deleted in the sandbox, and they must also be removed from production. Which approach best prepares the outbound change set and the release?
Question 2
In a sandbox, an administrator at Cloud Kicks built a custom object with several fields, a custom tab, a record-triggered flow that updates those fields, and a Lightning record page for the object. The outbound change set currently holds only the flow and the Lightning page. None of these components exist in production yet. Before uploading, what should the administrator do so the deployment carries everything those two components reference?
Question 3
At Northern Trail Outfitters, an administrator uploads an outbound change set from a sandbox to production. It holds a new custom object and a record-triggered flow. Validation in production fails because the flow references a custom picklist field on Account that exists only in the sandbox. The release must follow the change set process, with no manual setup in production. What should the administrator do?
Unlock Premium Access
Salesforce Certified Platform Administrator II
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 2973 Superior-grade Salesforce Certified Platform Administrator II practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- Admin II: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Change Set Components and Dependencies questions
25 questions (total)