Consulting and Implementation Strategies25% of the exam
Change sets, sandboxes and release readiness
How change sets behave (connections, one-transaction deploys, validation, locks, limits, what they cannot do), when to switch to Salesforce CLI, which sandbox fits each test, and how to regression test against a seasonal release in a preview sandbox.
During an implementation, outline and apply appropriate deployment considerations.
~8 min read · 16 practice questions ·
What the exam expects
- Apply change set rules: deployment connections and authorization, one-transaction deploys with no rollback after success, validation before a scheduled window, org locking, the 10,000-file limit and what change sets cannot carry.
- Recognize when change sets cannot do the job (unrelated orgs, deletes and renames, overrides on standard objects) and what to use instead.
- Choose the sandbox for development, UAT, training, staging and load testing.
- Plan release readiness: regression testing, sandbox preview before a seasonal release, and permission sets in the deployment plan.
Key terms:
- Outbound / inbound change set: sent from the org you are in / received from another org and deployed there.
- Deployment connection: the authorized link between a production org and its sandboxes that change sets travel over.
- Validation: a test deployment that returns the real success or failure messages without committing anything.
- Regression testing: retesting existing processes to catch changes that break what already worked.
- Sandbox preview: sandboxes upgraded to the next release before production.
Key facts
Who can exchange change sets
- Detail
- Only a production org and its sandboxes
Before the first upload
- Detail
- A target-org admin authorizes uploads on the connection
Production maintenance
- Detail
- Build outbound change sets, but no upload or authorization
Failed deploy
- Detail
- Whole transaction rolls back; restart manually
Successful deploy
- Detail
- Committed; can't be rolled back
File limit
- Detail
- 10,000 files per change set
Org lock
- Detail
- Data read/write allowed; no metadata changes
Apex in production
- Detail
- All local tests run by default; not automatic in sandboxes
Sandbox username suffix
- Detail
- Ignored during change set deployment
Refresh source
- Detail
- Production, or the source sandbox for a clone (production if that source is deleted)
Load testing
- Detail
- Full sandbox only
Quick deploy window
- Detail
- 10 days after validation, if no other deployment or major org change
Sources for this section (5)
- Implementation Tipshelp.salesforce.com (opens in a new tab)
- Best Practiceshelp.salesforce.com (opens in a new tab)
- Refresh Your Sandboxhelp.salesforce.com (opens in a new tab)
- Sandbox Types and Templateshelp.salesforce.com (opens in a new tab)
- Test and Deploy Changestrailhead.salesforce.com (opens in a new tab)
- Why validate an inbound change set before a scheduled window?
- When can a sandbox upload a change set to production?
- What can users do while a change set locks the org?
- Why test in a sandbox preview before a seasonal release?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Agentforce Sales Consultant pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 20 lessons of the Agentforce Sales Consultant guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (16 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams