Checklist progress
0/316Learned
Platform App Builder
Study Checklist
Checklist progress
0/316Learned
Given a set of business requirements, recommend a solution for managing the application lifecycle, including sandbox types
0/11
Given a use case, demonstrate knowledge, viability, and troubleshooting when using change sets.
0/16
Outbound versus inbound change sets
Learn this conceptDeployment connections and inbound authorization
Learn this conceptAffiliated-org limits for change sets
Learn this conceptUser permissions for change sets
Learn this conceptMetadata versus data in change sets
Learn this conceptComponents available in change sets
Learn this conceptCustom metadata type records in change sets
Learn this conceptProfile settings versus permission sets in change sets
Learn this conceptDelete and rename limits for change sets
Learn this conceptDependent components for change set deploy
Learn this conceptValidate a change set before deploy
Learn this conceptAll-or-nothing change set transaction
Learn this conceptApex tests on production change set deploy
Learn this conceptFlow activation after change set deploy
Learn this conceptClosed outbound change sets and cloning
Learn this conceptWhen inbound change sets become unavailable
Learn this conceptDescribe the use cases and considerations when using unmanaged and managed packages.
0/11
Given a scenario, determine the appropriate deployment plan.
0/6
Prepare for the Exam
Study Community
Ask questions and get the latest info from other Platform App Builder studiers. 592 members and growing.
An inbound change set is a package of configuration sitting in a target org, waiting to be deployed. Salesforce can take that package off the table so you can no longer deploy it, usually because it expired, was deleted in the source org, or the source sandbox was deleted or refreshed after the upload. If a change set you expected to deploy is missing or blocked, check those events first.