Destructive changes and manual deployment steps
How pre and post destructive changes manifests order deletions around a deployment, which settings Metadata API and change sets leave behind or change on arrival, how flows deploy as active, and how unsupported metadata types become runbook steps.
Given a scenario, describe approaches to handle pre and post deployment steps, including items not supported via the APIs.
~8 min read · 13 practice questions ·
What the exam expects
- Order deletions with pre and post destructive changes manifests, and predict how missing components, the Recycle Bin and tests behave.
- List the pre and post deployment steps that special deployment behaviours force: secrets, keys, group members, approval order, trusted sites, field access, profiles and master-detail data.
- Get flows to production active and with all their dependencies.
- Use the Metadata Coverage Report to turn unsupported metadata types into manual runbook steps.
Key terms: destructive changes manifest (a package.xml-format file listing components to delete), pre and post deletions (deletions processed before or after additions and updates), purgeOnDelete (skips the Recycle Bin for deleted components), special deployment behaviour (a documented case where a deployment drops, resets or creates something), runbook step (a manual action scheduled before or after the deployment).
Key facts
- Detail
- Not supported; name every component
- Detail
- Post destructive changes are processed before any tests run
- Detail
- Other deletions still attempted; a warning is raised
- Detail
- Developer Edition and sandbox orgs only
- Detail
- Readable and editable false unless field permissions are deployed
- Detail
- Creates a new profile with that name
- Detail
- Members aren't migrated
- Detail
- Inactive unless Deploy processes and flows as active is on
- Detail
- Metadata Coverage Report, per type and per channel
Sources for this section (6)
- Deleting Components from an Organizationdeveloper.salesforce.com (opens in a new tab)
- project deploy start (CLI command reference)developer.salesforce.com (opens in a new tab)
- deploy()developer.salesforce.com (opens in a new tab)
- Special Behavior in Deploymentshelp.salesforce.com (opens in a new tab)
- Deploy Processes and Flows as Activehelp.salesforce.com (opens in a new tab)
- Metadata Coverage Reportdeveloper.salesforce.com (opens in a new tab)
- Why should a deployment that deletes an Apex class through a post manifest run local tests?
- When can a deployment remove a profile's layout assignment for a record type?
- Why does changing an object's sharingModel and adding an owner-based sharing rule need separate deployments?
- Which channels does the Metadata Coverage Report compare for each metadata type?
The questions are free to read. Answers with their sources and self-grading are included with the pack.
Keep reading with the Platform Development Lifecycle and Deployment Architect pack
- Core concepts
- Exam traps
- Worked scenario
The pack includes:
- All 26 lessons of the Platform Development Lifecycle and Deployment Architect guide, with reading progress
- Interactive decision walks and step-by-step sequence steppers
- Inline practice questions and one-click topic practice (13 questions for this lesson)
- An official source cited for every claim
- An AI tutor that answers from the guide
- Unlimited timed practice exams