16.3 Release Readiness & Credential Maintenance

16.3 Release Readiness & Credential Maintenance

Quick Answer: Before production deploy, complete a release checklist: passing tests, ≥75% Apex coverage expectations, complete dependencies, planned data steps, and reviewed destructive changes. Use feature toggles when you can ship inactive and enable later. After deploy, run smoke tests on critical paths. Separately, keep your Salesforce Platform Developer credential current with Trailhead release maintenance modules—maintenance is how the cert stays valid across platform releases, which is different from studying for the initial exam.

Shipping metadata is only half of professional delivery. Platform Developer I expects you to think like someone who will not wake the on-call admin at 2 a.m.

Pre-Deploy Checklist

Treat the following as a mental (or team) gate. Exam scenarios often hide one missing item.

1. Functional completeness in a lower environment

• User stories accepted in QA/UAT with realistic profiles.
• Integration endpoints verified (named credentials, remote sites, connected apps).
• Feature flags defaulted safely for production.

2. Automated test health

Run the same test level you will use on production (or stricter) during validation.

3. Dependency and component inventory

• Custom fields, labels, custom metadata, permission sets, and layout assignments that Apex/LWC/Flow need.
• Order of operations for packages (core before apps).
• Manual post-steps documented (queue routing, sharing recalculation expectations, translator loads, etc.).

4. Data versus metadata plan

• Metadata via change set / CLI / package.
• Data via agreed migration (Data Loader, integration job)—with sandbox-proven mapping.
• Never assume “deploy will create the sample Accounts.”

5. Security and access review

• Permission sets reviewed; no accidental Modify All / View All.
• Profiles minimized.
• FLS on sensitive fields verified for each persona.

6. Rollback / mitigation thinking

Salesforce deploys are not always a simple one-click undo. Plan:

• Can you deploy a hotfix package quickly?
• Can a feature toggle disable the new path?
• Do you have a prior package version or known-good Git tag?
• Who is on call during the window?

Destructive Changes: Extra Caution

Destructive changes remove metadata (delete a field, class, or component). Risks:

• Hard-deleted fields can destroy data and break integrations.
• Deleted classes break packages or unmanaged references still in the org.
• Layouts, reports, and Flows may still reference “removed” members until cleaned.
• Package upgrade rules may block deletes until references are cleared.

Practices:

1. Prefer deprecate then delete across releases (hide from UI, stop writes, then remove).
2. Use explicit destructive manifest workflows in Metadata API/CLI rather than hoping a normal deploy deletes orphans.
3. Search the org (and source) for references—Apex, Flows, formulas, reports.
4. Communicate with admins and integration owners.
5. Back up data when field removal is involved.

Exam angle: if a question mentions deleting a field used in production reports, the safe answer emphasizes impact analysis and staged removal, not “just deploy without the field.”

Feature Toggles and Progressive Delivery

A feature toggle (feature flag) separates deploy from release:

Benefits:

• Deploy during a quiet window; enable when support is ready.
• Instant mitigation without reverse-deploying every component.
• Pilot users before global on.

Costs: flag debt—remove obsolete toggles so the org does not become unreadable. Toggles are not a substitute for tests; they complement release control.

Post-Deploy Smoke Tests

Unit tests prove code paths in isolation; smoke tests prove the org still works for humans and integrations after the package lands.

Minimum smoke set (adapt to the app):

1. Login as each major persona (Sales, Service, admin).
2. Create/update a critical record type that hits new automation.
3. Open primary Lightning pages / LWC entry points.
4. Confirm batch/scheduled jobs or platform events if in scope.
5. Spot-check integrations (auth works, callouts succeed or fail gracefully).
6. Verify permission-sensitive UI (users without the new permission set do not see pilot features).

Capture evidence (screenshots, ticket comments) for regulated environments. If smoke fails, toggle off or hotfix before broad announcement.

Release Window Hygiene

• Freeze conflicting admin changes during the window when possible.
• Avoid deploying large packages Friday evening without support coverage.
• Monitor Apex Exception Email, integration dashboards, and key business KPIs after go-live.
• Hold a short release retrospective: what validation missed, which test to add.

Credential Maintenance: Platform Developer Currency

Passing Platform Developer I is not the end of the credential story. Salesforce certifications are kept current through release-maintenance badges on Trailhead—one badge per certification per year—rather than by re-sitting the full exam on a fixed multi-year “exam again or expire” cycle.

How maintenance works (conceptual model for the exam)

1. Salesforce ships three seasonal releases a year (Spring, Summer, Winter) and publishes maintenance badges against them.
2. Credential holders complete one maintenance badge per certification per year—not one per release. Salesforce sets a dated deadline per badge (for example, a badge released in April 2026 is typically due by roughly the same point in 2027) and emails the holder.
3. Modules are typically free and focus on what changed that developers must know.
4. Completing maintenance keeps the credential current so your status remains active on the Salesforce certification directory.
5. Missing maintenance can move a credential to an inactive/expired maintenance state—requiring catch-up per Salesforce’s then-current policy (details can change; the exam-level idea is maintain via Trailhead release modules).

Exam prep versus ongoing currency

Do not confuse:

• Studying this guide for PDI exam day with
• Completing maintenance modules after you are certified.

Both matter for a career on the platform; only the first is “pass the test.” The second is “remain a current Salesforce Certified Platform Developer as releases ship.”

Practical tips for credential holders

• Watch Salesforce Certifications / Trailhead for maintenance due dates.
• Complete modules early in the window—do not wait for the last day.
• Use maintenance content as a lightweight way to learn new platform features (Flow, Apex, LWC, security) that may appear in future job work—and in later advanced certs.
• Company enablement programs sometimes assign maintenance; still verify your cert status personally.

Putting It Together: A Sample Production Story

1. Feature developed in scratch org / dev sandbox; source reviewed in Git.
2. CI deploys to integration; all tests green; coverage OK.
3. UAT signs off; permission sets scoped; feature flag off in production payload.
4. Production validate of package/change set during afternoon.
5. Deploy in evening window; smoke tests; enable flag for pilot users.
6. Monitor exceptions; expand pilot; remove flag next release.
7. Within the annual maintenance window, the developer completes the Trailhead maintenance badge so the cert stays current.

Exam Traps

• Believing change sets move data.
• Ignoring 75% coverage until production night.
• Deleting fields without reference checks.
• Equating “unit tests passed” with “users can work.”
• Claiming the developer cert never needs attention after exam day—or claiming it always requires a full paid re-exam every fixed multi-year period regardless of maintenance (learn the one-badge-per-year maintenance model).

Closing the Deployment Domain

Across this chapter you connected change sets, Metadata API / DX / packages, and release readiness. Together they map the Testing, Debugging, and Deployment weight: not only writing Apex, but shipping it safely and staying current through the annual maintenance badge as Salesforce releases three times a year. On exam questions, match the tool to the risk; on the job, automate the boring parts and checklist the dangerous ones.