Suggested answer

Three activities, all of them before the production upgrade rather than after it.

First, know the dates for your own instance, not a generic release date, and confirm which sandbox instances are designated preview instances for that release. Salesforce publishes both. Make sure a suitable sandbox is on a preview instance inside the preview window so there is somewhere to test on the new release while production is still on the old one.

Second, run risk-targeted regression there: the critical-path suite for broad breakage, plus focused testing wherever the release notes intersect the org's own customisations — changed behaviour on an object the code depends on, an altered default, a feature being retired.

Third, read the retirements and known issues. That is the part teams skip and the part that produces surprises, because a retirement is a deadline rather than a defect.

Around it I keep the release calendar clear: I do not schedule a major customer release into the same window as the platform upgrade, because when two things change at once, diagnosis time doubles. And I record the results by release name, since the same exercise runs three times a year and the previous pass tells me which areas are historically fragile.

Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.

Community comments (0)

No comments yet.

Sign in or create a free account to add a comment. Comments are moderated before they appear.

Plain text only, 3–2000 characters. A moderator reviews every comment before it is published.