Study guide
11.2 Change Set Dependency Tracking & Deployment Sequencing
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
11.2 Change Set Dependency Tracking & Deployment Sequencing
Key Takeaways Explain This Topic AI
The 'View/Add Dependencies' button in Outbound Change Sets analyzes selected metadata and surfaces required upstream components to prevent deployment validation failures.
Critical platform features are unsupported by change sets and must be manually configured, including standard picklist values not available as change-set components, org-wide email addresses, and fiscal year settings; verify business-process prerequisites before record-type deployment.
When a Profile is added to a change set, Salesforce only migrates permissions for the metadata components explicitly bundled in that change set, but other profile settings, such as user permissions and login IP ranges, can also deploy.
A rigorous deployment runbook sequences release activities across pre-deployment manual steps, change set deployment, and post-deployment manual activation and data seeding.
Custom fields created on standard objects can be deployed independently without bundling the entire standard object definition into the change set.
Last updated: October 2026
Change Set Dependency Tracking & Deployment Sequencing
One of the most frequent causes of change set deployment failure is missing metadata dependencies . When deploying a sophisticated declarative application—such as a custom object equipped with formula fields, validation rules, page layouts, custom tabs, email alerts, and record-triggered flows—Salesforce requires that all upstream referenced components either pre-exist in the target organization or be packaged alongside the primary component.
Furthermore, not all Salesforce platform features can be transferred via change sets. Successful application deployment requires an app builder to master dependency tracking, understand the strict boundary between supported and unsupported metadata, and execute a structured deployment runbook comprising pre-deployment and post-deployment manual steps.
Dependency Management & The "View/Add Dependencies" Engine
When you add a primary component to an Outbound Change Set, Salesforce does not automatically bundle all related child or dependent components. For example, adding a Custom Object does not automatically pull in its custom fields, custom tabs, or page layouts.
To address this, Salesforce provides the View/Add Dependencies button on the Outbound Change Set detail page:
After adding your core components, click View/Add Dependencies .
The platform queries the internal metadata dependency registry and displays a list of all upstream components referenced by the items already in your change set.
Common dependencies identified by the tool include:
Custom Fields referenced in Formula Fields, Validation Rules, or Record-Triggered Flows.
Global Value Sets referenced by custom picklists.
Custom Email Templates and Letterheads referenced by Email Alerts.
Custom Report Types referenced by Reports and Dashboard components.
Custom Fields on Standard Objects referenced by Lightning Record Pages.
If you deploy a change set containing a validation rule that references Discount_Rate__c , but Discount_Rate__c does not exist in the target org and is omitted from the change set, the inbound validation fails immediately with an error: Field Discount_Rate__c does not exist . [Primary Component Added]
- Record-Triggered Flow
- │
- ▼ References
- ┌──────────────────────────────────────────────┐
- │ Email Alert ──> Email Template ──> Letterhead
- │ Custom Field ──> Global Value Set │
- └──────────────────────────────────────────────┘
- ▲
- [View/Add Dependencies]
- Identifies and bundles all required upstream metadata
Note
Deploying Custom Fields on Standard Objects: You cannot add a standard object (such as Account or Contact ) to a change set. To deploy new custom fields on standard objects, navigate to the Custom Field component type in the change set builder and select the specific custom fields (e.g., Account.Customer_Segment__c ).
The Profile Deployment Trap in Change Sets
A major area of confusion on the Platform App Builder exam involves how User Profiles interact with change sets:
When you add a Profile (e.g., Custom: Sales Rep ) to an outbound change set, Salesforce does not deploy the entire profile definition .
Instead, the deployment engine only transfers the profile's permissions for the specific components included in that exact change set .
For example, if your change set contains Custom_Object__c and the Custom: Sales Rep profile, the target org updates permissions for Custom_Object__c on that profile. Custom component permissions depend on included supporting components, while profile settings can also carry user permissions, login IP ranges, tab settings, and assignments. Review the payload rather than assuming everything unrelated is untouched.
If you deploy a custom field without including any profiles or permission sets, the field deploys with Hidden field-level security for all profiles in the target org (except System Administrator).
Important
Profiles vs. Permission Sets: Because profiles only migrate permissions for components explicitly bundled in the change set, managing security via profiles in change sets is fragile and error-prone. Modern Salesforce architecture strongly recommends deploying security access using Permission Sets , which migrate their full, self-contained permission definitions independently.
Supported vs. Unsupported Components in Change Sets
Salesforce supports hundreds of metadata types in change sets, but several critical application components cannot be deployed using change sets and require manual configuration in the target environment.
Component Type Change Set Support Status Architectural Handling & Strategy
Custom Objects & Fields Fully Supported Added directly; remember to add custom tabs and page layouts via dependencies.
Salesforce Flows Fully Supported Deploy as active if Apex tests pass; otherwise deploy inactive and activate post-deployment.
Validation Rules Fully Supported Deployed alongside the parent object or as independent child components.
Permission Sets Fully Supported Deploy full definitions; assign to target users post-deployment.
Standard Picklist Values Unsupported Modifying values on standard fields (e.g., Lead.LeadSource , Opportunity.StageName ) must be configured manually in the target org.
Sales / Lead / Support Processes Verify target prerequisites and dependency/tool support Ensure the required process and selected standard values exist before deploying dependent record types; use manual setup or supported metadata tooling where needed.
Organization-Wide Email Addresses Unsupported Must be manually configured and verified via email confirmation in the target organization prior to deployment.
Currencies & Exchange Rates Unsupported Enabling multi-currency, active currencies, and conversion rates must be configured manually under Company Information.
Fiscal Year Settings Unsupported Custom fiscal year configurations must be defined manually in the target org.
Web-to-Lead / Web-to-Case Unsupported HTML generation and endpoint/reCAPTCHA configuration need target review; Auto-Response Rule is a supported change-set component.
Data Records (Seed / Master Data) Unsupported Change sets deploy metadata only; record data (Accounts, Products, Price Books) requires Data Loader or CLI.
Pre-Deployment and Post-Deployment Sequencing (Runbook)
Complex enterprise deployments must be structured into an ordered execution runbook to prevent deployment validation failures and ensure continuous system availability. ┌─────────────────────────────────────────────────────────────────┐
- │ DEPLOYMENT RUNBOOK STAGES │
- ├─────────────────────────────────────────────────────────────────┤
- │ STAGE 1: PRE-DEPLOYMENT MANUAL STEPS │
- │ • Configure Org-Wide Email Addresses and verify sender inbox │
- │ • Add standard picklist values and configure Sales Processes │
- │ • Enable platform feature licenses (Multi-Currency, etc.) │
- │ • Temporarily disable validation rules or Apex triggers │
- ├─────────────────────────────────────────────────────────────────┤
- │ STAGE 2: METADATA CHANGE SET DEPLOYMENT │
- │ • Validate inbound change set (Dry Run) │
- │ • Execute deployment (Default / Specified Tests) │
- ├─────────────────────────────────────────────────────────────────┤
- │ STAGE 3: POST-DEPLOYMENT MANUAL STEPS │
- │ • Activate newly deployed Flows and Assignment Rules │
- │ • Assign newly deployed Permission Sets to business users │
- │ • Migrate master/seed data (Price Books, Products, Settings) │
- │ • Re-enable validation rules and execute smoke testing │
- └─────────────────────────────────────────────────────────────────┘
- Stage 1: Pre-Deployment Manual Tasks
Before deploying the inbound change set, administrators must prepare the target environment:
Org-Wide Email Addresses: If a deployed Flow or Email Alert sends emails from support@universalcontainers.com , that address must already exist and be verified in the target org. Otherwise, the change set will fail to deploy.
Standard Picklist Values & Business Processes: If a new Record Type relies on a new Opportunity Stage, the stage value must be manually added to Opportunity.StageName in the target org, and the corresponding Sales Process must be created.
Feature Enablement: Features like State and Country Picklists, Multi-Currency, or Digital Experiences must be activated manually if the incoming metadata depends on them.
Stage 2: Metadata Deployment
Validate and deploy the inbound change set using the appropriate test option, checking deployment logs for any unresolved dependencies.
Stage 3: Post-Deployment Manual Tasks
After the change set commits successfully:
Flow & Rule Activation: Verify whether flows and lead/case assignment rules deployed as active; activate them manually if necessary.
Security Assignment: Assign deployed Permission Sets to designated users or user groups.
Master Data Seeding: Use Data Loader or Salesforce CLI to insert lookup records, product catalogs, price book entries, or custom setting records that the declarative automation requires.
Smoke Testing: Execute representative business transactions to verify that validation rules, formulas, and flows operate as designed.
Tip
Deployment Runbook Documentation: Always maintain a standardized deployment checklist for every release. Documenting exact pre-deployment and post-deployment manual steps ensures repeatable, audit-compliant releases and eliminates high-stress guessing during production maintenance windows.
Official Source Check
Checked October 19, 2026: Permission sets and profile settings in change sets .