Overview
App Deployment is the smallest section of the Platform App Builder exam, but at 13% it grew from 10% in the Summer '26 update. Its four objectives cover recommending a solution for managing the application lifecycle, including sandbox types, using change sets with an understanding of when they work and how to fix failures, deciding between unmanaged and managed packages, and choosing an appropriate deployment plan for a scenario.
These objectives are about moving metadata safely. An app builder should know which environment suits development, integration testing, user acceptance and training, what change sets can and cannot carry, and when a package is the better delivery vehicle. DevOps Center and source-driven development appear in the official prep trail as the modern alternatives, so the exam expects awareness of them alongside change sets.
How it's tested
Questions give a project situation, such as a team size, data needs, timeline or distribution goal, and ask for the right sandbox, deployment tool or package type. Change set questions often describe a failed or incomplete deployment and ask for the cause. Planning questions ask for the next step or the best release approach.
-
Choose the sandbox
A testing or development need is described with data volume and refresh frequency, and you pick Developer, Developer Pro, Partial Copy or Full.
-
Why did the change set fail
Components are missing, the target org rejects the deployment or tests fail, and you identify dependencies, connection settings or unsupported components.
-
Package or deploy
An app must be distributed, upgraded or kept editable, and you choose unmanaged, managed or unlocked packages, or a direct deployment.
A company wants to load-test a new flow against production-sized data and replicate real record volumes for user acceptance. Developer and Developer Pro sandboxes copy metadata only. A Partial Copy sandbox holds a sample defined by a template and is capped at 5 GB. Only a Full sandbox copies all production data, so it fits performance and final acceptance testing, despite its longer refresh interval.
Objectives 4
Official objectives from the Salesforce outline, in outline order.
5.1 Given a set of business requirements, recommend a solution for managing the application lifecycle, including sandbox types.Plan, develop, test and release across the right environments.
- What it means
- Application lifecycle management is the process of planning, building, testing, releasing and monitoring changes. Salesforce provides four sandbox types: Developer and Developer Pro copy metadata only with small storage, Partial Copy adds a sample of production data selected by a sandbox template, and Full copies all data and metadata. Changes move between environments using change sets, DevOps Center, the Salesforce CLI or packages.
- What to understand
- Know the trade-offs: Developer sandboxes (200 MB data storage) refresh daily and suit individual building; Developer Pro (1 GB) suits larger development and integration testing; Partial Copy (5 GB, five-day refresh) suits quality assurance and training with realistic samples; Full sandboxes (29-day refresh) suit performance testing, staging and user acceptance. Know that DevOps Center adds source control with work items as a modern alternative to change sets.
- How it shows up
- A scenario describes a testing or development need and asks which sandbox or lifecycle step fits.
- Common confusion
- Choosing a Full sandbox for every need, despite its long refresh interval and limited availability.
5.2 Given a use case, demonstrate knowledge, viability, and troubleshooting when using change sets.Outbound and inbound change sets, deployment connections and common failures.
- What it means
- A change set sends metadata from one org to another related org, such as sandbox to production. An outbound change set is built in the source org and uploaded; it appears as an inbound change set in the target, where it can be validated and deployed. A deployment connection must allow inbound changes, and both orgs must be connected to the same production org.
- What to understand
- Know the limitations: change sets do not delete or rename components, cannot include some metadata types, and do not carry data. You must add dependent components yourself; the View/Add Dependencies option helps. Deployments to production run Apex tests. Validation lets you check a deployment first and then quick deploy. A change set cannot be edited after upload, so a fix needs a new change set.
- How it shows up
- A deployment fails or is incomplete; you identify missing dependencies, an inbound connection not authorized, or an unsupported component.
- Common confusion
- Expecting a change set to delete a field or move data from sandbox to production.
5.3 Describe the use cases and considerations when using unmanaged and managed packages.Distributing apps as editable unmanaged packages or upgradeable managed packages.
- What it means
- Packages bundle metadata for distribution. Unmanaged packages are often used for templates or open-source sharing; once installed, the components can be edited by the subscriber, but they cannot be upgraded by the developer. Managed packages belong to a namespace, protect intellectual property, can be upgraded, and are the standard way partners distribute apps on AgentExchange.
- What to understand
- Know that installed managed package code is hidden and most components are locked, though subscribers can add fields and automation around them. Managed packages count against separate limits and support license management. Unlocked packages are a second-generation option for internal teams that want versioned, modular delivery while keeping components editable.
- How it shows up
- A scenario describes sharing a template, selling an app or modularizing internal metadata; you pick unmanaged, managed or unlocked packaging.
- Common confusion
- Using an unmanaged package when the publisher must push upgrades later, which unmanaged packages cannot support.
5.4 Given a scenario, determine the appropriate deployment plan.Release planning: tools, testing, timing, communication and rollback.
- What it means
- A deployment plan decides what moves, how, when and with what checks. It covers the tool (change set, DevOps Center, Salesforce CLI or package), the testing sequence through sandboxes, the release window, user communication and training, and what to do if something fails. Some changes, such as page activation or permission assignment, may need manual post-deployment steps.
- What to understand
- Know good practice: validate before deploying to production, schedule releases outside peak hours, coordinate with Salesforce seasonal releases and sandbox preview windows, activate flows deliberately, and document manual steps. Larger teams benefit from source control and DevOps Center for tracking work. A rollback plan matters because some deployments cannot be reversed simply.
- How it shows up
- A question describes release risk or team size and asks for the most appropriate deployment approach or next step.
- Common confusion
- Deploying directly to production without validation or user acceptance testing because the change seems small.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Developer sandbox
Metadata-only copy with 200 MB data storage, refreshable daily.
- Remember
- Suited to building and unit testing by one developer or admin.
- Tested as
- Common answer for isolated development.
- Trap
- Picking it when realistic data volumes are needed.
-
Developer Pro sandbox
Metadata-only copy with 1 GB data storage, refreshable daily.
- Remember
- More room for test data and integration work.
- Tested as
- Fits larger development and testing.
- Trap
- Assuming it copies production records.
-
Partial Copy sandbox
Metadata plus a sample of production data defined by a sandbox template.
- Remember
- Up to 5 GB data storage; five-day refresh interval.
- Tested as
- Used for QA, testing and training with realistic data.
- Trap
- Forgetting it needs a template to choose data.
-
Full sandbox
Complete copy of production data and metadata.
- Remember
- 29-day refresh interval.
- Tested as
- Used for performance tests, staging and final user acceptance.
- Trap
- Choosing it for daily development.
-
Outbound change set
A set of components built and uploaded from the source org.
- Remember
- It cannot be edited after upload.
- Tested as
- Built in the sandbox you are deploying from.
- Trap
- Expecting to fix it in place after upload.
-
Deployment connection
Authorization that lets an org receive inbound change sets.
- Remember
- Both orgs must share the same production org.
- Tested as
- Missing authorization is a common failure cause.
- Trap
- Trying to send change sets between unrelated orgs.
-
Validate and quick deploy
Test a deployment without committing, then deploy the validated set.
- Remember
- Saves time in the release window.
- Tested as
- Appears in planning and troubleshooting questions.
- Trap
- Skipping validation for production releases.
-
Unmanaged package
Editable bundle of components with no upgrade path.
- Remember
- Subscribers own the components after install.
- Tested as
- Fits templates and sample apps.
- Trap
- Expecting the publisher to push upgrades.
-
Managed package
Namespaced, upgradeable, IP-protected bundle.
- Remember
- Standard for AgentExchange distribution.
- Tested as
- Fits commercial apps that must be upgraded.
- Trap
- Expecting to edit its locked components.
-
DevOps Center
Salesforce tool for tracking work items and moving changes with source control.
- Remember
- A modern alternative to change sets.
- Tested as
- Shows up as an option for team-based release management.
- Trap
- Assuming it removes the need for testing environments.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Sandbox types
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Developer | Metadata only, 200 MB data, daily refresh. | Smallest and most frequently refreshable. | Using it for data-heavy testing. |
| Developer Pro | Metadata only, 1 GB data, daily refresh. | More storage than Developer. | Assuming it includes production data. |
| Partial Copy | Metadata plus sampled data, 5 GB, five-day refresh. | Data chosen by a sandbox template. | Forgetting to define a template. |
| Full | All data and metadata, 29-day refresh. | Mirrors production for staging and performance. | Using it for routine development. |
Delivery mechanisms
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Change set | Moves metadata between related orgs through the UI. | No deletions, no data, manual dependency selection. | Expecting it to remove obsolete fields. |
| Unmanaged package | Distributes editable components. | No upgrades after install. | Choosing it for an app needing future versions. |
| Managed package | Distributes protected, upgradeable components. | Namespace and locked code. | Choosing it for an internal template others will edit. |
| DevOps Center | Tracks work and promotes changes with source control. | Team-oriented pipeline instead of manual change sets. | Treating it as a sandbox type. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Full sandbox for everything
- What candidates pick
- Use a Full sandbox for a single admin's new feature work.
- Why it looks right
- It has the most realistic data.
- Why it's wrong
- It refreshes only every 29 days and is a scarce resource; a Developer sandbox suits isolated building.
Clue to watch for One person building and testing a small change.
-
Change set deletes
- What candidates pick
- Include the old field in a change set to remove it from production.
- Why it looks right
- Change sets seem to synchronize orgs.
- Why it's wrong
- Change sets only add or update components; deletions are done manually or with destructive changes through other tools.
Clue to watch for The requirement is to remove or rename components.
-
Data in the change set
- What candidates pick
- Add reference records to the change set.
- Why it looks right
- Teams want production to match the sandbox.
- Why it's wrong
- Change sets move metadata only; records must be loaded with data tools.
Clue to watch for The scenario mentions records, not configuration.
-
Edit after upload
- What candidates pick
- Open the uploaded change set and add the missing field.
- Why it looks right
- It feels like a draft that can be updated.
- Why it's wrong
- An uploaded change set is locked; clone it, add the component and upload again.
Clue to watch for A deployment failed due to a missing component after upload.
-
Unmanaged for a product
- What candidates pick
- Distribute a commercial app as an unmanaged package.
- Why it looks right
- It is simple to create.
- Why it's wrong
- Unmanaged packages cannot be upgraded and expose all code, so commercial apps use managed packages.
Clue to watch for The publisher plans future versions or protects its code.
-
Unrelated org
- What candidates pick
- Send a change set from a Developer Edition org to production.
- Why it looks right
- Both are Salesforce orgs.
- Why it's wrong
- Change sets only work between orgs connected to the same production org.
Clue to watch for The source is a separate Developer Edition or another company's org.
Answer framework
Use these steps to choose environments and deployment tools for a release scenario.
- Clarify the goal of each environment, such as development, integration testing, user acceptance, training or performance testing.
- Match each goal to a sandbox type using data needs, storage and refresh interval, saving Full sandboxes for staging and performance work.
- Choose the delivery tool: change sets for simple moves between related orgs, DevOps Center or the CLI for team source control, and packages for distribution.
- Build the release list with all dependencies, validate in the target, and note manual steps such as page activation or permission assignment.
- Schedule the release, communicate with users, run acceptance tests, keep a rollback plan, and monitor the org after deployment.
Practice question
Want more like this? The Platform App Builder practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Memorize the sandbox table first, because several quick questions depend on it: storage, data copied and refresh interval for each type. Then practice change sets hands-on if you have a sandbox, or follow the Trailhead change set modules closely. Build an outbound change set with a custom field, a flow and a permission set, use View/Add Dependencies, upload it, authorize the connection, validate and deploy.
Next, read the Package Development Model and Unlocked Packages modules from the official prep trail to understand how packages differ from org-based deployments. Write a short comparison of unmanaged, managed and unlocked packages in your own words. Skim the DevOps Center quick look so you can recognize it as an option in team scenarios. Finally, sketch a release plan for an app from the other sections, listing environments, tools, manual steps and rollback, and finish with timed questions that mix sandboxes, change set failures and package choices.
FAQ
How much of the Platform App Builder exam covers App Deployment?
App Deployment is 13% of the current exam, about eight scored questions. It was 10% before the Summer '26 update.
Do I need to know sandbox refresh intervals?
Yes. Know that Developer and Developer Pro sandboxes refresh daily, Partial Copy every five days and Full every 29 days.
Can change sets deploy to any Salesforce org?
No. Change sets only work between orgs connected to the same production org, such as its sandboxes and the production org itself.
Is DevOps Center on the exam?
The official prep trail includes a DevOps Center quick look, so recognize it as a tool for tracking work and moving changes with source control.
What is the main difference between managed and unmanaged packages?
Managed packages are namespaced, protect code and can be upgraded. Unmanaged packages give the subscriber editable components but cannot be upgraded by the publisher.
Do change sets move flow activations?
A flow version arrives as metadata, but activation may need to be checked or done in the target org as part of the deployment plan.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- HubSpot Inbound Marketing Certification Study guide
- Salesforce Certified Platform Developer I Study guide
- Google Ads Search Certification Study guide
- ServiceNow Certified System Administrator Study guide
- Salesforce Certified Platform Administrator Study guide
- ServiceNow Certified Application Developer Study guide
Test your Domain 5 knowledge
Check your recall of sandbox types, change set rules and package choices with practice questions, then take a readiness check across all five sections.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Platform App Builder AI tutor Get any concept explained your way