16.3 Release Readiness & Credential Maintenance

Salesforce Certified Platform Developer I Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Blueprint Weights & Study Strategy

2 Platform Fundamentals

2.1 Multi-Tenant Architecture & Shared Resources 2.2 MVC Mapping on the Lightning Platform 2.3 Declarative vs Programmatic Decisions 2.4 Agentforce for Developers: Use Cases & Limitations

3 Data Modeling & Schema

3.1 Objects, Fields & Schema Design 3.2 Relationship Types & Implications 3.3 Schema Design Impact on Apex 3.4 Data Import & Export for Development

4 Platform Data Features

4.1 Formula Fields & Roll-Up Summaries 4.2 Core CRM Objects & Standard Schema 4.3 AppExchange Extensions & Platform Boundaries

5 Declarative Process Automation

5.1 Record-Triggered Flows & Declarative Automation 5.2 Approval Processes & Business Rules 5.3 When to Use Apex vs Declarative Tools

6 Apex Language Basics

6.1 Variables, Constants & Apex Data Types 6.2 Lists, Sets & Maps 6.3 Control Flow & Exception Handling 6.4 Classes, Interfaces & OOP Patterns

7 SOQL, SOSL & DML

7.1 SOQL Query Fundamentals 7.2 SOSL Search Fundamentals 7.3 DML Operations & Bulkification 7.4 Governor Limits & Transaction Boundaries

8 Apex Triggers & Order of Execution

8.1 Trigger Structure & Context Variables 8.2 Bulk Trigger Patterns & Best Practices 8.3 Save Order of Execution 8.4 Recursion, Cascading & Transaction Control

9 Asynchronous Apex

9.1 @future Methods 9.2 Queueable Apex 9.3 Batch Apex 9.4 Schedulable Apex & Job Orchestration

10 Security, Events & Schema Access

10.1 Sharing, FLS, CRUD & Injection Prevention 10.2 Platform Events Publish & Subscribe 10.3 Programmatic Schema Access (Describe)

11 Visualforce

11.1 Visualforce Pages & Markup 11.2 Standard, Custom Controllers & Extensions 11.3 Visualforce in Lightning Experience

12 Lightning Components

12.1 Lightning Component Framework Benefits 12.2 Aura Component Structure & Resources 12.3 Lightning Web Components Fundamentals 12.4 LWC Data Access: Wire, Imperative & Events

13 UI Composition & Apex Integration Patterns

13.1 Composing UI in Lightning Apps 13.2 UI Security, Performance & Accessibility Patterns 13.3 Apex Actions for Flow, LWC, and Agentforce

14 Apex Testing

14.1 Testing Framework & Coverage Requirements 14.2 Writing Unit Tests for Triggers & Classes 14.3 Test Data Strategies & Isolation 14.4 Executing Tests & Execute Anonymous Differences

15 Debugging & Developer Tools

15.1 Debug Logs & Monitoring 15.2 Developer Console, CLI, VS Code & Workbench 15.3 Sandboxes, Scratch Orgs & Environment Strategy

16 Deployment & Release

16.1 Change Sets & Metadata Deployment 16.2 Unlocked Packages, Metadata API & Salesforce DX 16.3 Release Readiness & Credential Maintenance

16.3 Release Readiness & Credential Maintenance

Key Takeaways Explain This Topic AI

Release readiness means tests pass, coverage meets production thresholds, dependencies are complete, and data vs metadata steps are planned before the window opens

Destructive changes (deleting metadata) need explicit handling and impact analysis—never assume a normal deploy removes obsolete components safely

Feature toggles (custom settings/metadata, permissions, Custom Permissions, release flags) reduce risk by shipping dark and enabling after smoke checks

Platform Developer certification stays current through one free Trailhead release-maintenance badge per year—not a one-time multi-year shelf life, and not one badge per seasonal release

Platform Developer certification stays current through free Trailhead release maintenance modules—not a one-time multi-year shelf life if you complete required maintenance

Last updated: August 2026

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

Check Why it matters
All relevant Apex tests pass Failed tests block or break production deploys
Overall coverage ≥ 75% after deploy rules Platform production requirement
Triggers covered Explicit deployment expectation
Critical paths have assertions, not empty tests Empty tests inflate coverage without safety
SeeAllData avoided unless justified Brittle tests fail when data differs

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:

Prefer deprecate then delete across releases (hide from UI, stop writes, then remove).

Use explicit destructive manifest workflows in Metadata API/CLI rather than hoping a normal deploy deletes orphans.

Search the org (and source) for references—Apex, Flows, formulas, reports.

Communicate with admins and integration owners.

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 :

Mechanism Example use
Custom Permission + permission set Enable new LWC actions for a pilot cohort
Hierarchy Custom Setting / Custom Metadata Turn off a new discount engine path
Custom label / CMDT-driven Flow decision Route 10% of cases to new automation
Permission set group activation Time-box access during rollout

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):

Create/update a critical record type that hits new automation.

Open primary Lightning pages / LWC entry points.

Confirm batch/scheduled jobs or platform events if in scope.

Spot-check integrations (auth works, callouts succeed or fail gracefully).

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)

Salesforce ships three seasonal releases a year (Spring, Summer, Winter) and publishes maintenance badges against them.

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.

Modules are typically free and focus on what changed that developers must know.

Completing maintenance keeps the credential current so your status remains active on the Salesforce certification directory.

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

Concern Initial exam prep Ongoing maintenance
Goal Pass the multiple-choice exam Stay certified as the platform evolves

Content depth Broad blueprint (fundamentals, automation, UI, test/deploy) Release deltas and updated best practices

Primary artifact Study guides, practice questions, hands-on orgs Trailhead release maintenance modules for your cert

Cadence Once (plus retakes if needed) One badge per year, per certification
Cost model (typical) Exam fee Maintenance modules generally free

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

Feature developed in scratch org / dev sandbox; source reviewed in Git.

CI deploys to integration; all tests green; coverage OK.

UAT signs off; permission sets scoped; feature flag off in production payload.

Production validate of package/change set during afternoon.

Deploy in evening window; smoke tests; enable flag for pilot users.

Monitor exceptions; expand pilot; remove flag next release.

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.