Six weekends between your preview sandbox and the release.
Make them count.

Common questions about Salesforce release regression testing

How is this different from Provar, Copado or ACCELQ?

Those tools ask you to move your regression suite into their platform and their format. Lastest runs Playwright inside your own network, writes the tests into your repo as readable code, and compares the rendered screen — not just the assertion result. The three of them are strong on functional coverage of Salesforce metadata; none of them diff what the Lightning page actually looked like before and after the release weekend. Teams run both without conflict.

Do we need a git repo to use this?

A repo is where the value lands, but it is not a hard requirement to start. Lastest emits plain Playwright TypeScript files; you can run them from the Lastest instance alone. Most release teams commit them so the regression pack is version-controlled alongside the change set it protects, and so the tests survive a change of tooling, vendor or staff.

Does it work against a preview sandbox?

Yes, and that is the intended use. A preview sandbox sits on a different API version from the rest of your pipeline, which is why most deployment tooling keeps it out of the pipeline entirely. Lastest does not deploy anything, so the API version mismatch is irrelevant to it. It signs in through the browser like a user, walks your flows, and captures the screens. It works the same way against a pre-release org, a full copy sandbox, a partial copy sandbox, or production.

What happens to our tests if we stop using Lastest?

You keep them. They are Playwright files in your repo and screenshot artifacts in your storage. There is no proprietary model repository to export from, and no re-authoring project if you leave. This is deliberate: every buyer who has migrated off an enterprise test platform has paid for the privilege once already.

Our Apex test classes all pass. What would this catch that they do not?

Apex test classes assert server-side behaviour. They cannot see that a tab was renamed, that a field moved to a different column of the page layout, that a Lightning component now renders below the fold, or that an Experience Cloud page lost its branding. Salesforce admins describe this failure mode consistently: no red errors, just things silently not working until a user notices. A screen-level diff is what surfaces it, and it surfaces it during the preview window rather than after the release weekend.

We missed the sandbox refresh cutoff. Is it too late to test early?

Once the cutoff passes, the only way to change a sandbox to a preview instance is to refresh it onto one, which is no longer possible for that release — so your remaining sandboxes stay on the current version until the non-preview instances upgrade on 9 and 10 October. You can still baseline your org now and diff it immediately after your production release weekend, which shortens the window between a regression appearing and someone seeing it. Then set a reminder for the next refresh cutoff, and request the refresh about a week early: Salesforce warns of processing backlogs at the deadline.

Does anything leave our network?

No. Lastest is self-hosted. The runner, the browsers, the baselines and the diff images all sit on infrastructure you control, and org data never reaches us. Recording a flow uses a model to author the Playwright code; you can point that at your own endpoint, and replay never calls a model at all.

How do we handle Release Updates and other changes Salesforce enforces on a schedule?

Read the release notes and the Release Updates list to decide what to enable and when, then use the baseline as the control. Enable a Release Update in the preview sandbox, replay the regression pack, and the diff report shows exactly which screens moved. That report is the artifact you take to UAT sign-off, rather than a spreadsheet of steps someone ticked at 9pm on a Friday.