11.2 Change Set Dependency Tracking & Deployment Sequencing

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:

1. After adding your core components, click View/Add Dependencies.
2. 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.
3. 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

---

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).

---

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.

---

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:

1. 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.
2. 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.
3. 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:

1. Flow & Rule Activation: Verify whether flows and lead/case assignment rules deployed as active; activate them manually if necessary.
2. Security Assignment: Assign deployed Permission Sets to designated users or user groups.
3. 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.
4. Smoke Testing: Execute representative business transactions to verify that validation rules, formulas, and flows operate as designed.

Official Source Check

Checked October 19, 2026: Permission sets and profile settings in change sets.