Spring 25 Admin and Developer Guide | SalesforceTutorial

Spring 25 is the Salesforce Spring ’25 major release, mapped to API version 63.0. For most teams, the important work is not reading every release note; it is deciding which permission changes, Flow updates, Apex behavior changes, and integration release updates can affect users in production.

This guide explains the spring 25 items that Salesforce admins, developers, and architects should still know in 2026, especially when maintaining orgs that were upgraded from Spring ’25 to the summer 25 release and later releases. Use the official Salesforce Spring ’25 release notes as the source of record, then use the checks below to plan regression testing.

Spring 25: what changed in the Salesforce release

The spring 25 release covered platform, security, Flow, Apex, Lightning Web Components, Sales Cloud, Service Cloud, Marketing Cloud, and Agentforce changes. In enterprise orgs, the safest way to consume the release is to group work by owner: admin configuration, developer build changes, integration endpoints, automation, and regression testing.

The official spring ’25 release notes are versioned under release 254. That matters because Salesforce Help now shows newer releases by default. When you audit an older decision, verify that the URL contains release=254 so you are reading the spring 25 source, not a later Summer, Winter, or Spring page.

Spring ’25 release notes and API version 63.0

The spring ’25 release notes align platform developer changes with API version 63.0. Salesforce also documents Flow versioned updates for Spring ’25 API version 63.0. Do not bulk-update every Apex class, trigger, LWC, or Flow API version just because the org moved to spring 25. Update versioned metadata only after tests prove that the changed runtime behavior is acceptable.

Salesforce spring 25 release planning by role

How should admins test spring 25 permission and UI changes?

Admins should treat spring 25 as a security review, not only a feature release. Permission changes can reduce setup work, but they can also expose fields more broadly than a team expects if the permission set is assigned to the wrong users.

Sort list views by multiple columns

Multi-column sorting for list views became generally available in spring 25. Salesforce documents the feature for list views and related lists, including the user action to choose multiple columns and sort order from the list view interface. See the official list view note for multi-column sorting.

Test this with service queues, renewal lists, and sales pipeline views. The feature changes how users inspect records, but it does not replace report filters, sharing rules, or validation logic. If your org uses list views as operational work queues, confirm the default sort order with the team before changing saved views.

View All Fields object permission

The View All Fields object permission lets an assignee read all fields for a supported standard or custom object, including fields created later. Salesforce describes this permission in the official View All Fields release note and in Trailhead maintenance content. It does not replace record-level access. A user still needs record access through org-wide defaults, role hierarchy, sharing rules, teams, territories, manual sharing, or Apex sharing.

Use this permission for controlled technical personas, such as backup, data quality, or integration users, only after a field-level access review. Do not assign it to broad business groups just to avoid maintaining field permissions. If a new sensitive field is added later, View All Fields can make that field readable to any assignee.

Permission set group summaries

Spring 25 also improved permission review work by exposing more actions through summaries. For example, Salesforce Trailhead’s Spring ’25 admin maintenance unit references managing included permission sets in permission set groups from summaries. In an enterprise org, this is useful during access reviews because the admin can inspect group composition without switching through several setup pages.

Before changing a permission set group, export the current assignments, identify muting permission sets, and confirm whether the group is part of a managed package. Managed package permission sets can have upgrade behavior that differs from local permission sets.

What developer changes matter in the salesforce spring 25 release?

The salesforce spring 25 release introduced developer-facing work that matters most when you save code or metadata at API v63.0. Developers should test these changes in a sandbox with realistic data volume, not only with small unit-test fixtures.

Apex ZIP support became generally available

Native ZIP handling in Apex became generally available in spring 25 through the Compression namespace. Salesforce documents Compression namespace classes, including ZipWriter and ZipReader, and the Apex Developer Guide includes a ZIP support page for creating and extracting archives.

The following Apex example creates a Salesforce File containing a ZIP archive with one JSON entry. It uses with sharing, checks object access, applies WITH SECURITY_ENFORCED for queried fields, and keeps the archive small to avoid heap pressure.

public with sharing class Spring25ZipExportService {
    public class ExportException extends Exception {}

    @AuraEnabled
    public static Id createAccountExportZip(Id accountId) {
        if (accountId == null) {
            throw new ExportException('accountId is required.');
        }

        if (!Schema.sObjectType.Account.isAccessible()) {
            throw new ExportException('You do not have access to Account.');
        }

        Account accountRecord = [
            SELECT Id, Name, Industry
            FROM Account
            WHERE Id = :accountId
            WITH SECURITY_ENFORCED
            LIMIT 1
        ];

        Map<String, Object> payload = new Map<String, Object>{
            'id' => String.valueOf(accountRecord.Id),
            'name' => accountRecord.Name,
            'industry' => accountRecord.Industry
        };

        Compression.ZipWriter writer = new Compression.ZipWriter();
        writer.addEntry('account.json', Blob.valueOf(JSON.serialize(payload)));
        Blob zipBody = writer.getArchive();

        if (!Schema.sObjectType.ContentVersion.isCreateable()) {
            throw new ExportException('You do not have access to create files.');
        }

        ContentVersion version = new ContentVersion(
            Title = 'account-export-' + accountRecord.Id,
            PathOnClient = 'account-export-' + accountRecord.Id + '.zip',
            VersionData = zipBody
        );
        insert version;

        return version.Id;
    }
}

Governor limit note: ZIP creation works in Apex memory. Large files can hit heap size, CPU time, or DML limits. For bulk exports, queue work in smaller jobs, store intermediate files, and test with production-sized files before enabling the feature for users.

LWC local development and API version 63.0

Salesforce’s developer guidance for Spring ’25 described Local Dev as generally available for Spring ’25 sandboxes and scratch orgs. The feature was later renamed Live Preview in Spring ’26 documentation. The current official LWC Live Preview documentation explains that saved source changes can update the preview without a manual browser refresh, and Salesforce recommends using it in sandbox and scratch orgs.

For LWC code saved at API version 63.0, review selector behavior, TypeScript checks if your team uses TypeScript, and mobile/offline linting. Keep the component’s API version stable until unit tests, Jest tests, and UI regression tests pass.

API v63.0 Apex behavior checks

The official Salesforce Developer Spring ’25 guide notes several API v63.0 behavior changes, including exception JSON serialization changes, stricter Apex behavior when reparenting master-detail children where reparenting is not allowed, and a changed default Accept header for Apex callouts. These are versioned behaviors, so an old class may keep old behavior until you save it at a newer API version.

Use a small utility for org-domain endpoints instead of hard-coded instance names in Apex or integration setup:

public with sharing class MyDomainEndpointBuilder {
    public class InvalidPathException extends Exception {}

    public static String buildOrgEndpoint(String relativePath) {
        if (String.isBlank(relativePath) || !relativePath.startsWith('/')) {
            throw new InvalidPathException('relativePath must start with /.');
        }

        return URL.getOrgDomainUrl().toExternalForm() + relativePath;
    }
}

This pattern supports the My Domain release update and reduces breakage when Salesforce moves an org between instances. Still review middleware, named credentials, external services, connected apps, CI scripts, and vendor configuration because Apex is only one place where instance URLs can hide.

How do Flow updates in spring 25 affect automation?

Flow teams should review spring 25 changes with the same discipline used for Apex changes. A screen flow can fail users just as quickly as code when field permissions, validations, or reactive behavior are not tested.

Built-in visual progress indicators for Screen Flows

Salesforce added built-in visual progress indicators for Screen Flows in spring 25. The official release note explains that builders configure the indicator from flow version properties, and Salesforce Help documents how to set up a standard progress indicator.

Use progress indicators when a flow has a clear sequence, such as eligibility, details, review, and confirmation. Avoid them when the flow branches heavily and the user may skip stages, because inaccurate progress is worse than no progress indicator.

Create Flows with a new streamlined creation experience

The salesforce release notes spring 25 automation section includes a streamlined Flow creation experience. Salesforce describes a reorganized creation window that helps builders choose the automation type faster. This helps new builders, but it does not change the design decision: choose record-triggered Flow, scheduled-triggered Flow, screen Flow, platform event-triggered Flow, or Apex based on transaction scope, limits, and maintenance ownership.

Automatically triggered screen actions were Beta in Spring ’25

Screen actions that run automatically when related input values change were marked Beta in Spring ’25. Treat Beta features as candidates for controlled pilots. Before using them in production-critical onboarding, case intake, or guided selling flows, test validation order, error handling, accessibility, and whether the action creates unexpected DML or callout volume.

What release updates should be checked before the summer 25 release?

The spring 25 release created follow-up work that continued into the summer 25 release. The most important items are integration endpoints, legacy API usage, and security-related release updates.

Salesforce release notes spring 25 release updates checklist

• My Domain API URLs: Salesforce documented a release update requiring API calls to use the My Domain login URL instead of instance-specific URLs. Review Apex, middleware, Postman collections, CI jobs, data tools, and managed package settings.
• Legacy Platform API versions: Salesforce’s API end-of-life policy states that API versions 21.0 through 30.0 are retired as of Summer ’25. Review REST, SOAP, and Bulk API clients and move them to a supported version after regression testing.
• Einstein Activity Capture access: If Sales Engagement Basic users relied on bundled access, confirm the proper Einstein Activity Capture permission assignment in the release updates area.
• Return email address verification: Validate sender verification for users who send email from Salesforce, especially shared sales or support mailboxes.

Summer 25 release comparison for teams maintaining older orgs

Use the Salesforce Summer ’25 release notes to confirm whether an item that was new, Beta, or pending in spring 25 changed status later. The summer 25 release is especially relevant for integration owners because retired API versions can fail after enforcement even if the same integration appeared to work during spring 25 testing.

Best practices for upgrading metadata after spring 25

Do not treat API version upgrades as a find-and-replace task. In a production org, use this sequence:

1. Inventory Apex classes, triggers, Flows, LWCs, Aura components, Visualforce pages, external integrations, and managed packages.
2. Identify items already saved at API v63.0 or later.
3. Run unit tests and UI tests before changing API versions.
4. Upgrade one functional area at a time, such as case intake automation or renewal integrations.
5. Review debug logs, event monitoring, Flow error emails, and integration logs after deployment.

For related implementation guidance, see Salesforce admin configuration guides, Salesforce Flow tutorials, Lightning Web Components examples, and Apex development tutorials.

Frequently Asked Questions