Published at: 2026-09-17
change-set-component-dependency-reference
Component dependencies determine whether a change set can deploy successfully in the target environment.
[!WARNING] The following tables are organized based on the original manual and Salesforce Help dependency concepts. Specific automatic inclusion rules require manual review.
Core concept summary
Components in a change set may depend on other components. If the target environment lacks a dependent component and the change set does not include it, deployment may fail.
Common dependencies
| Selected component type | Common dependent components |
|---|---|
| Object | Fields, layouts, validation rules, record types, import settings |
| Field | Its object, field permissions, global variables, common option sets |
| Button | Related scripts, object mapping rules |
| Layout | Fields, buttons, actions, UI events, assignment settings |
| Import settings | Related scripts |
| Custom role | Business function permissions, field permissions |
| Preset role | Business function permissions, field permissions |
| Approval flow | User groups, scripts, node handlers |
| Business flow | User groups, scripts, node handlers |
| Workflow | User groups, scripts, node handlers |
| Stage advancer | User groups, fields, node handlers |
Automatic dependency rules for outbound change sets
When you select certain component types in an outbound change set, the system automatically packages the components associated with the selected component into the outbound change set. After the outbound change set is uploaded, the components automatically depended on by the selected components appear in the outbound change set’s component list.
| Selected component type | Associated component types automatically added to the change set |
|---|---|
| Object | Import settings, layouts, validation rules, fields, and record types related to the selected object |
| Field | APL code, global variables, and common option sets related to the selected field |
| Button | APL code and object mapping rules related to the selected button |
| Layout | APL code related to the selected layout. UI events and the enable new/edit page layout toggle sync with the new/edit page layout; assignment layout settings sync with the layout or role |
| Import settings | APL code related to the selected import settings |
| Custom role | Business function permissions and field permissions related to the selected role |
| Preset role | Business function permissions and field permissions related to the selected role |
| Approval flow | User groups and APL code related to the selected approval flow. Node handler information for all dimensions is copied |
| Business flow | User groups and APL code related to the selected business flow. Node handler information for all dimensions is copied |
| Workflow | User groups and APL code related to the selected workflow. Node handler information for all dimensions is copied |
| Stage advancer | User groups and fields related to the selected stage advancer. Node handler information for all dimensions is copied |
Check recommendations
| Check item | Description |
|---|---|
| Does the object exist | Fields, layouts, and rules depend on objects |
| Does the field exist | Layouts, flows, and rules may depend on fields |
| Are permissions complete | Roles and permission configurations affect user access |
| Does the user group exist | Flow nodes may depend on user groups |
| Do people and departments match | People and departments created in a sandbox may have different IDs from the production environment |
Important limits
Avoid creating people or departments in a sandbox and directly publishing related metadata.
IDs of people and departments may not match across environments. Deploying metadata that includes people or department dimensions can produce unexpected results.