Salesforce Winter '27 Release: Key Dates, What Breaks, NPSP Impact

Winter '27 production upgrades have begun. If your org is waiting for an October upgrade, use the remaining time for sandbox testing. If it has already upgraded, start by checking the processes staff depend on every day.

Before working through an August checklist, check what is still on it. Salesforce canceled Adopt Authorized Email Domains, postponed the OAuth username-password flow retirement, and now lists five Release Updates enforced with Winter '27. An older checklist may send you after the wrong deadline.

For nonprofit admins, start with permissions and integrations: can staff complete the same approvals and donation processes, and can each integration still authenticate? Then review the changes for the products you actually use. This guide separates NPSP considerations from Agentforce Nonprofit features, with a practical test plan for the upgrade window.

When is the Salesforce Winter '27 release?

Salesforce's admin calendar lists September 4, October 2, and October 9, 2026 as the main Winter '27 rollout dates. The September window has passed. Your org's exact upgrade date and time come from its maintenance event in Salesforce Trust.

Salesforce separately announces October 12, 2026 as general availability. That is not another production upgrade window. Individual features still have the availability conditions stated in their release notes.

Keep the time zone with the date when you share the release plan. An instance's event may fall on the following calendar day in UTC: for example, the completed USA1000 production upgrade started on September 5 at 03:00 UTC.

Setup → Company Information → Instance

Salesforce Trust → search that instance → Maintenances → Winter '27 release event

Use the production instance, not the sandbox instance. The August 28 sandbox preview milestone was a separate step in the release schedule.

If production is already on Winter '27, check recent integration failures and scheduled jobs before changing settings. If the org upgrades in October, finish the sandbox tests and assign someone to repeat the critical checks after the upgrade.

Later deadlines belong on a separate planning calendar:

Start with the Winter '27 Release Updates that are actually enforced

Which Release Updates are enforced in Winter '27?

The official list under Release Updates → Enforced with This Release contains five items. The updates displayed in Setup depend on the org; do not expect every org to show five identical pending cards.

• Profile Filtering, which limits visibility of profile names for users without View All Profiles.
• Assign Use Any API Auth Permission for SOAP login(), which requires that permission for users authenticating through SOAP login().
• Accessibility enhancements for page headers and modal windows above 200% zoom.
• Accessibility enhancements for date pickers, popovers, bottom utility bars, and record headers.
• Accessibility enhancements for cards, docked containers, menu lists, and panels.

The August 19 PDF listed four enforced updates; the September 2 PDF listed five, including the SOAP permission requirement. That comparison explains why an older checklist may show four. For subsequent changes, check Salesforce's release note change log and the current enforced list.

Keep the five enforced updates separate from canceled items and later deadlines. Then review any additional product-specific changes that apply to the org.

Was the Adopt Authorized Email Domains release update canceled?

Yes. Adopt Authorized Email Domains is one item that can come off the Winter '27 preparation list. Salesforce canceled that Release Update and replaced it with Maintain Your Email Verification Exception. The official Release Updates page now lists the original item under Canceled Updates.

The replacement is enforced on December 1, 2026, but it appears only in orgs where Salesforce Support previously disabled user email verification for a domain.

Setup → Release Updates → Maintain Your Email Verification Exception

If the replacement update appears in the org, configure an authorized domain and test the affected users and return addresses. If it does not apply, do not create a project just to implement the canceled update. Other email requirements still need their own review.

Is the OAuth username-password flow retired in Winter '27?

No. The OAuth username-password flow for Connected Apps does not retire when the org upgrades to Winter '27. Salesforce postponed that retirement until February 20, 2027. OAuth user-agent and hybrid user-agent flows have the same enforcement date.

That postponement is not a reason to defer every authentication change. For CRM Analytics Salesforce external input and output connections, the Winter '27 release note instructs customers to move existing connections to OAuth before the upgrade and warns that legacy credentials will stop working.

The connector documentation is narrower: it says an existing username-and-password connection can still function with SOAP login() enabled, but changing its credentials requires OAuth. Those descriptions do not fully agree.

For an affected connection, follow the release note's earlier deadline: migrate and test before your org upgrades. If production is already on Winter '27, check the sync now and plan a controlled migration; do not disable a working connection just to reproduce a failure. Migrating early costs implementation and testing time. Waiting risks a stopped sync or an urgent conversion when credentials change. The February deadline is not a safe planning date for this connector.

What API version does Salesforce Winter '27 use?

Winter '27 uses API version 68.0, and LWC API 68.0 has no version-specific changes. That is useful context, but it does not mean every pinned API or runtime version should be raised at once. An API-version change should still go through the same regression process as any other code change.

What changes automatically when the org is upgraded to Winter '27?

Profile Filtering is the first test we would run

Once Profile Filtering is enforced, a user without the View All Profiles permission can see only their own profile name.

User management is the obvious place to check, but profile information can also be referenced in approval processes, assignments, reports, formulas, Flow, Apex, and custom components that inspect another user's profile.

There is no single failure mode that applies to every implementation. Depending on how the org is configured, an assumption about profile visibility can result in unexpected behavior, null values, or no visible issue at all. Testing only as a System Administrator will miss many of these cases.

Test as: ordinary user → each privileged operations role → admin.

Run the same approvals, assignments, reports, Flows, formulas, Apex, and custom UI for each persona. If something fails, avoid solving the problem by giving View All Profiles to everyone. Assign it only where there is a documented need. If the issue goes beyond Profile Filtering, review the affected user's profile, permission sets, role, and record access before changing permissions.

The accessibility updates change how Lightning reflows above 200% zoom

Three of the five enforced updates affect the way Lightning content reflows above 200% zoom. Page headers, modal windows, date pickers, popovers, utility bars, record headers, cards, docked containers, menus, and panels can wrap or move.

The latter two updates depend on the page-header update, so enable that dependency first when testing.

This deserves attention even if accessibility testing is not normally part of the release checklist. A custom component that looks fine at standard zoom can overlap or interfere with a standard control once the surrounding Lightning container begins to reflow.

Browser zoom: 200% → 400%. Check keyboard focus, labels, reachable actions, modal buttons, and custom components beside standard Lightning content.

Prioritize pages staff use regularly: gift entry, program, case, grant, report, quick-action, and portal pages.

Apex heap rises to 10 MB and 25 MB, which can hide a mixed-version failure

The synchronous Apex heap limit increases from 6 MB to 10 MB, while the asynchronous limit increases from 12 MB to 25 MB. The extra capacity is useful, but large collections, attachments, response bodies, and serialized payloads can still create problems.

The main risk during the release window is the version mismatch. Code can pass in a Winter '27 preview sandbox and then fail when deployed to a Summer '26 production org because production still has the smaller heap.

Salesforce provides a nonproduction setting that enforces the Summer '26 heap limit so teams can test exactly this scenario.

The current heap-limit note makes the setting available in Winter '27 nonproduction orgs, including sandboxes, Developer Edition, and scratch orgs. It does not disappear when the connected production org upgrades. In Spring '27, the higher limits apply globally regardless of the setting.

Winter '27 nonproduction org → Setup → Apex Settings → Enforce the Summer '26 Apex heap limit

Use Limits.getLimitHeapSize() to confirm the limit before rerunning the affected transactions. Once both environments use Winter '27 limits, the mixed-version deployment risk no longer applies.

Flow waits and retries during record-lock contention

When a Flow encounters record-lock contention during transaction initialization, Salesforce now waits 10 seconds and retries instead of failing immediately with UNABLE_TO_LOCK_ROW.

That may turn a previously failed transaction into a successful one. It can also make the transaction slow enough for an external caller to time out.

For that reason, transaction duration should now be part of the test result rather than checking only whether the Flow succeeds. Re-run bulk imports, scheduled automation, and mass reassignment. Pay particular attention to processes where multiple transactions update the same household, donor, campaign, program, case, or summary record, and check for duplicate downstream work as well as the final status.

Screen and autolaunched Flows also get an optional security change. On runtime API 68.0, they can consistently enforce the running user's permissions. Existing Flows do not all change automatically, so test the security context, total run time, transaction count, callouts, and fault handling before enabling the option.

There is also a smaller deployment change worth knowing about. Saving an existing auto-layout Flow now stores End elements explicitly in its XML. The business logic may not have changed, but the source-control diff will. Save and retrieve a representative Flow before the first Winter '27 deployment so reviewers and metadata tooling can distinguish the mechanical XML change from an actual logic change.

Agentforce Platform is being enabled automatically

One platform change is easy to overlook because it does not sit inside the nonprofit sections. Agentforce Platform is enabled by default when new Winter '27 orgs are created, and eligible existing orgs are being enabled on a rolling basis starting in the first week of September.

Salesforce says enabling the platform does not add cost or change billing.

That does not mean end users suddenly receive an active agent. Access to Agentforce Builder still depends on Einstein generative AI being enabled, other users require the appropriate permissions, and an agent has to be activated before it can be used.

The practical implication is that admins may find Agentforce Builder available even if nobody explicitly enabled it. Review the permissions rather than assuming that availability means users have access. To give other users access, assign the Manage AI Agents permission. The platform itself can be turned off by disabling the Einstein setting in Setup.

Which Winter '27 features are worth opening in a preview sandbox?

Once the existing org has been regression-tested, Winter '27 includes several additions worth exploring. Whether they belong in production should depend on the problem they solve, not simply on the fact that they are new.

Screen Flows can run as mass quick actions. Users can select records in a list view or related list and run one guided process against the selection. For nonprofits, that could support controlled bulk stewardship, participant follow-up, or grant-review work.

The release notes say the Flow receives the selected record IDs but do not specify the selected-record variable name or type. Verify that contract in a Winter '27 org before turning the feature into an internal development standard.

Flow Test Mode is in beta. Admins can save scenarios and assertions for record-triggered and autolaunched Flows. Mock outputs can isolate Action and Subflow elements, including HTTP callouts that should not reach a live endpoint during testing.

This can make regression testing more repeatable, but a beta testing tool should not be the only evidence used to approve a production deployment.

A few smaller changes are worth checking when they solve a specific need:

• Flow tags can classify automation, and Edit History can restore supported versions.
• User field history can track up to 20 fields.
• Report record preview is in beta.
• If the nonprofit uses an LWR Experience Cloud site, beta report and dashboard embedding may help with a partner, participant, board, or reviewer portal. For Lightning reports, contact Salesforce Customer Support to enable the beta first; the note lists Professional, Enterprise, and Unlimited editions. Test authenticated access and confirm that guest users cannot see information they should not receive.
• Agentforce deployments gain AiAgentDefinition and AiAgentDefinitionVersion metadata types in API 68.0. Both orgs must be on 68.0. During the mixed-version period, continue using the previous metadata types at API 67.0.
• If the org uses Gemini 2.5 Pro, Flash, or Flash-Lite, those requests are rerouted to Gemini 3.5 equivalents starting the week of October 20, 2026. Test affected prompts before then because responses can change.

What does Winter '27 mean for an NPSP org?

Salesforce's current product naming makes this part of the release particularly easy to misread.

Winter '27 affects NPSP orgs because NPSP runs on the Salesforce platform, but the release does not introduce an NPSP-specific feature. The terms NPSP and Nonprofit Success Pack do not appear in the Winter '27 Release Notes.

These notes do not announce an NPSP retirement, a migration deadline, or an automatic move to Agentforce Nonprofit.

NPSP remains a separate suite of managed packages, and Salesforce has not discontinued it.

What has changed is the licensing path for new organizations. The Power of Us application now offers approved organizations either ten Agentforce Nonprofit licenses or ten Sales and Service licenses.

NPSP itself is not a license type, so it is not one of those two choices. An organization that chooses Sales and Service can still install the NPSP packages separately.

Those licensing choices do not create a Winter '27 migration deadline for an existing NPSP org. If a move is already on the roadmap, treat the move from NPSP to Nonprofit Cloud as a separate architecture project with its own scope and timeline.

For an NPSP-only org, Winter '27 preparation is mainly platform regression testing: Profile Filtering, high-zoom pages, donation Flows and Apex, Experience Cloud forms, installed packages, and payment, email, accounting, backup, or ETL integrations.

For an Agentforce Nonprofit org, the product-specific work sits mainly in Program, Case, and Outcome Management setup, Fundraising, and Grantmaking.

If the organization uses both products or is partway through a transition, document which installed package, object, license, and integration owns each process before making release-related changes. The Winter '27 release name does not resolve that architecture decision.

What changes for Agentforce Nonprofit?

The notes state that Nonprofit Cloud is now called Agentforce Nonprofit. This is a product-name transition. It does not rename NPSP and does not move NPSP data into the newer product.

Availability still depends on the organization's Nonprofit Cloud products, edition, and add-ons. Seeing a feature in the release notes does not mean it is licensed in every nonprofit org.

Admins can configure Program Management, Case Management, and Outcome Management through guided steps in Salesforce Go. Based on the release note, Salesforce Go should be treated as a guided setup entry point rather than a new data model or migration requirement.

Open Salesforce Go from the gear menu and locate the relevant Program Management, Case Management, or Outcome Management setup journey.

Check the Program Participant Portal requirements

The Program Participant Portal template provides preconfigured pages for programs, applications, enrollments, benefit assignments and disbursements, and referrals.

Salesforce specifies Lightning Experience in Enterprise, Unlimited, and Developer editions, with Program Management and Track Applications enabled. The feature is available in Nonprofit Cloud and Education Cloud with the Program and Case Management for Experience Cloud add-on. Participants need the permission set of the same name; admins creating the site need Create and Set Up Experiences.

Check the entitlement before planning a sandbox trial. Then test with a participant account, not just the administrator who built the site: can that participant see the intended records without seeing someone else's information? The template is a starting point, not evidence that your sharing configuration is correct.

What are the Winter '27 Fundraising features?

Fundraising gets two related household features in Winter '27.

First, a gift-entry user can select Auto Create Household for a person account donor. If the donor does not already have a household, Salesforce creates one. The /gifts and /commitments APIs support the same behavior through shouldAutoCreateHousehold=true.

Second, admins can define formulas for household names and greetings. Salesforce recalculates those values when household membership or member details change.

Setup → Household → Group Membership → Household Naming Settings

Both features require Enterprise, Unlimited, or Developer edition of Agentforce Nonprofit or Agentforce Education with the Automatic Household Creation and Naming add-on.

The checkbox is only the visible part of the change. Behind it, Salesforce can create a household and its relationships, recalculate names and greetings, and affect household credit attribution. The official notes list nine supporting object and field changes:

Three of those entries relate directly to credit attribution. If the organization is moving from NPSP or currently runs both products, compare the new household behavior with its existing NPSP soft-credit rules. The underlying objects are different, but the organization's recognition policy still needs to produce the intended result.

As part of testing, create a gift, open the resulting household, verify its relationships and naming, and confirm the hard-credit, soft-credit, and household totals. Repeat the scenario through the API. Existing customers should also review field-level access and page layouts before exposing the new fields to users.

What changed in Grantmaking?

Grantmaking admins can now use Action Plan Templates that target the Application Form Evaluation object for repeatable, multi-stage application evaluations.

More importantly, Compliant Data Sharing can restrict individual reviewers to their assigned evaluation sections through the new AppFormEvalSectionPtcp object.

This is the Grantmaking change we would prioritize in testing.

Test as Reviewer A and confirm that only the assigned sections are available. Repeat the test as Reviewer B with a different assignment, then test as the process owner and confirm access to the complete evaluation.

Availability: Enterprise, Unlimited, and Developer editions for Agentforce Nonprofit and Agentforce Public Sector customers with Grantmaking. The availability line in the notes still uses the older Nonprofit Cloud name.

Separate the work by product: household creation and credit attribution in Fundraising, reviewer access in Grantmaking, and participant access if the organization plans to use the new portal. Do not turn all three into projects for an NPSP-only org.

What can break in an existing integration after Winter '27?

The integration we worry about is rarely the newest one. It is the old donation import, backup job, accounting sync, or vendor package that has worked quietly for years, so nobody remembers which authentication flow, SOAP version, or hostname it uses.

Start with ownership. For every connection, record the app type, authentication flow, API version, endpoint, integration user, vendor, monitoring, replacement plan, test date, and deadline.

That inventory should belong to a named integration owner rather than being reconstructed from login history during release week.

SOAP login() now requires a specific user permission. The Winter '27 note says every user authenticating through SOAP API login() must have Use Any API Auth.

SOAP login() is disabled by default in orgs created from Winter '26 onward. That org-level control is separate from the user's permission: enabling one does not replace the other.

Setup → Permission Sets → your SOAP integration permission set → System Permissions → Use Any API Auth

Identify the users that actually call SOAP login(), test each integration in nonproduction, and assign the permission only to the integration users that need it. Broadly granting an authentication permission across the org creates unnecessary access.

SOAP login() has a separate retirement deadline. The login() call in SOAP API versions 31.0 through 64.0 retires in Summer '27; it is already unavailable in version 65.0 and later. This is a retirement of the authentication operation, not every SOAP API operation in those versions.

That combination means an integration cannot simply move its existing login() request to version 65.0. Identify the affected job or vendor tool, assign a named owner, and plan a supported replacement. Follow the retirement guidance as the schedule develops.

Platform API versions 31.0 through 40.0 have a separate retirement schedule. This should not be confused with the SOAP login() retirement above.

SOAP, REST, and Bulk API versions 31.0–40.0 are deprecated in Summer '27 and retired in Summer '28, after which calls using those versions fail. This does not change the saved API versions of Apex classes, triggers, Visualforce pages, or Flows.

Standard-volume platform events retire December 15, 2026. After that date, publishing and subscribing stop working.

Salesforce provides a migration button in Setup. Before using it, stop publishing and let subscribers, including triggers and Flows, finish processing. Publishing does not work while migration runs, so schedule a maintenance window and wait for completion before resuming it.

Setup → Platform Events → migrate standard-volume events to high volume

After migration, retest every Flow, Apex trigger, and Streaming API client that subscribes to those events. In a nonprofit org, this is an easy dependency to miss because platform events are often part of older integrations that receive little day-to-day attention.

Device Flow changes earlier. On November 30, 2026, it becomes restricted to eligible local External Client Apps with a localhost callback. Move affected Connected Apps to an appropriate External Client App design.

Connected Apps are not shut down by Winter '27, but in Summer '27 their integrations and authorization flows stop receiving Salesforce support and bug fixes.

Salesforce's schedule for hard-coded instance URLs is still moving, but the remediation is already clear. The release notes say enforcement was postponed until Spring '27 and will happen in phases.

For the individual phases, Salesforce points to a separate End-of-Support Schedule. That page places sandbox enforcement between October 22 and November 5, 2026, and production enforcement between January 12 and March 25, 2027.

The page currently contains an inconsistency: the table places production enforcement in Spring '27, while the introduction still says production enforcement begins in November 2026.

Do not wait for Salesforce to make the prose tidy.

Search middleware → scripts → CI/CD → Named Credentials → vendor settings for instance-specific hosts.

Replace stale instance hosts with the org's My Domain login URL.

Setup → My Domain → Redirections → Block API traffic that uses an incorrect instanced URL

The control is now available in sandboxes. Enable it there and run every affected integration end to end, then confirm the production instance's date against the live schedule.

If enforcement occurs later than expected, the organization has simply completed a supported endpoint migration early. If an earlier phase catches an integration first, calls to the stale host return 400 Bad Request and the integration stops.

What is deprecated or retiring in Winter '27?

Treat the list below as an inventory, not as a list of automatic projects. If the organization does not use an affected product or configuration, mark the item as not applicable and move on.

Salesforce maintains the dated list on its Active Product & Feature Retirements page.

Check these additional dates only if the org uses the affected configuration:

• September 30 — Marketing Cloud installed-package secrets last rotated before March 25.
• October — start of Microsoft EWS disablement.
• Week of October 20 — Gemini 2.5 Pro, Flash, and Flash-Lite requests reroute to Gemini 3.5 equivalents for affected licensed orgs.
• October 31 — legacy Snowflake shares.
• November 10 — Trialforce domains.

In supported Enterprise, Performance, Unlimited, and Developer orgs — and Salesforce notes that the feature is not available in every org — Salesforce can revoke an affected user's active sessions and refresh tokens and force a password reset when it detects a credential-related issue such as credential stuffing.

This is not a scheduled password reset for all users. The reason to document it is simply to prevent an unexpected security reset from being misdiagnosed as an outage.

A practical Winter '27 test plan

If production is waiting for its October upgrade, run these checks in a Winter '27 sandbox first and repeat the critical paths after the upgrade. If production has already upgraded, use the list to check current behavior and investigate failures. Keep tests that remove permissions or change settings in nonproduction; do not recreate them against live users and integrations.

Before running the tests

1. Fix the calendar. Record the production instance and its Trust maintenance event, the sandbox instance, and whether that sandbox is on the preview track.
2. Choose people and processes, not generic test users. Reproduce an ordinary user, each privileged operations role, and an admin. List the donation, program, case, grant, report, portal, and approval paths each persona must be able to complete.
3. Give every integration an owner. For each connection, record the authentication flow, app type, API version, endpoint, user, vendor, monitoring, test date, and replacement deadline. Search middleware, scripts, CI/CD, Named Credentials, and vendor settings for Salesforce instance hosts, and include platform events in the inventory.

In a Winter '27 sandbox

4. Run the profile test first. Repeat the same approvals, assignments, reports, Flows, formulas, Apex, and custom UI with ordinary, privileged, and admin personas. An admin-only result is not enough.
5. Test integration authentication. In the sandbox, confirm the SOAP login control and test each affected user with and without Use Any API Auth. For CRM Analytics Salesforce external connections, test the OAuth configuration and a complete sync before cutover.
6. Zoom the pages staff cannot avoid. Test them at 200% and 400% with a keyboard as well as a mouse. Confirm that important controls remain visible, reachable, and usable.
7. Stress the expensive automation paths. Cover synchronous and asynchronous Apex, scheduled and bulk Flows, and scenarios where two transactions update the same record. If the code must still deploy to Summer '26 production, re-run it with the older heap setting. Measure Flow duration as well as success.
8. Put representative Flows through deployment. Save and retrieve an auto-layout Flow, inspect the new End-element metadata, and confirm that review or normalization tooling handles it correctly. If a Flow moves to runtime 68.0 or a different user context, include a permissions test.
9. Separate Experience Cloud personas. Test guest and authenticated access independently. If the org used the discontinued Experience Delivery beta, republish it on standard LWR infrastructure first.
10. Test the nonprofit product that is actually installed. For NPSP, cover critical donation and integration paths. For licensed Agentforce Nonprofit, test household creation through relationships, naming, credits, totals, and reviewer access. If adopting the Program Participant Portal, test the participant's record access. Organizations transitioning between the two products need both sets of tests and a documented source of truth.

Before and after the production upgrade

11. Wake up the quiet jobs. Run representative monthly, quarterly, and annual automation in the Winter '27 sandbox rather than waiting for its normal execution date. After the production upgrade, check scheduled-job results and integration monitoring; do not rerun donation or payment jobs blindly and risk duplicate processing. Assign owners to applicable retirement deadlines and mark the rest as not applicable.

Every critical test needs an owner, a recorded result, and a follow-up action where needed. If production has already upgraded, assign those owners now rather than waiting for the next release.

How is Winter '27 Release different from Summer '26 Release?

Summer '26 used API version 67.0; Winter '27 uses 68.0. For release planning, however, the more important difference is the type of risk involved.

Do not carry the Summer '26 preparation list forward unchanged. For Winter '27, distinguish what is enforced at the upgrade from what is canceled, postponed, or specific to a product such as CRM Analytics.

For Winter '27, we would spend the first testing hours on Profile Filtering, SOAP authentication, accessibility reflow, the mixed-version Apex heap issue, changed Flow timing, and older integrations.

Agentforce Nonprofit customers then have product-specific changes to evaluate, including Fundraising, Grantmaking, and the Program Participant Portal where licensed. NPSP-only customers do not need to turn a platform release into an artificial product-migration deadline.

For the earlier baseline, see the Salesforce Summer '26 release guide; the API 67.0 source remains the Salesforce Summer '26 Release Notes.

What Salesforce has not said yet

The release notes reviewed for this guide do not settle these planning questions:

• The price of the Automatic Household Creation and Naming add-on, or whether a nonprofit licensing program includes it.
• The retirement release for Apex metadata versions 9.0–19.0.

Until Salesforce publishes those details, avoid building them into a committed scope, budget, or deadline. For licensing questions in particular, get written confirmation for the specific organization rather than assuming that a feature mentioned in the release notes is included.

Based on the September 2 official Salesforce Release Notes, with targeted checks of the rollout calendar, Release Updates, authentication guidance, portal requirements, Apex heap settings, and LWR report availability on September 11, 2026.