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

If you have been following Winter '27 coverage, you probably already have a preparation list: update the OAuth integration, configure Authorized Email Domains, review the half dozen enforced changes, then work on the new features.

That list is probably wrong.

Salesforce canceled one of the Release Updates, delayed the OAuth date, and now lists only four Release Updates for Winter '27 enforcement.

Meanwhile, the changes most likely to surprise a nonprofit are the quiet ones:

• An ordinary user can no longer see another user's profile name.
• A Flow may take longer because it now retries a locked record instead of failing.
• Code tested in a preview sandbox can use more heap than production has before its upgrade.

These are my impressions of this release. Winter '27 is not a reason to rebuild a working org or to accelerate an NPSP migration. It is a reason to clean up the release plan, test permissions and integrations with real user roles, and only then decide whether any of the nonprofit changes fit the products the organization actually owns.

The official Winter '27 Release Notes referenced in this article were revised August 19, 2026, and continue to have a preview note. Beta, pilot, and developer preview items are worth testing, but not production promises.

If you only have an hour, read the four enforced Release Updates below, confirm your own upgrade date in Trust, and run the Profile Filtering test. If the org runs NPSP, the nonprofit sections will save you time by telling you what to skip. If the org runs Agentforce Nonprofit, the Fundraising and Grantmaking sections are where the actual product work is. Most of what follows is platform work that applies to any Salesforce org; the nonprofit-specific changes sit in two sections near the end.

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 four items:

• Profile Filtering, which limits visibility of profile names for users without View All Profiles.
• 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.

You will see Winter '27 checklists with five, six, or eight enforced updates. They combine this list with changes scheduled for later releases or with items that are not in the notes at all. Do not turn those numbers into six or eight org workstreams. Start from the four official entries, then check which other dated changes actually apply to the org.

Was the Adopt Authorized Email Domains release update canceled?

Yes. The clearest example of work you can drop is Adopt Authorized Email Domains. Salesforce canceled that Release Update and replaced it with Maintain Your Email Verification Exception; the official Release Updates page now places 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, set up an authorized domain and test users and return addresses. If it does not, there is no Winter '27 email-domain project.

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

No. The OAuth username-password flow is another false Winter '27 fire drill. It is not retired when the org upgrades. Salesforce postponed the retirement to February 20, 2027; OAuth user-agent and hybrid user-agent flows now retire on the same date. That is still a real migration, but it belongs on a planned integration calendar rather than the upgrade-weekend checklist.

That distinction matters. Release readiness is challenging enough without spending nonprofit budgets on projects Salesforce has already dropped or deferred.

When is the Salesforce Winter '27 release?

There is no single production weekend that applies to every reader, and even the published calendars do not agree. Salesforce's current admin countdown lists September 4, October 2, and October 9. Apex Hours lists August 29, October 3, and October 10. Software Insights reports five Trust windows: August 29, September 5, October 3, October 9, and October 10. Salesforce's Sandbox Preview Instructions give only a rule of thumb: production starts roughly six weeks after the August 28 preview begins.

In some cases, there may be descriptions for the same maintenance weekend in different time zones. However, the pages fail to define August 29 and explain the differences between October 2 and October 3. In any case, there are no more precise deadlines than the one linked to the organization's instance.

Setup → Company Information → Instance

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

Use that event for testing, user communication, and the change freeze. Until it appears, treat August 29 as the earliest credible risk boundary, not as a promised upgrade date. If that is too conservative, the work finishes early. If you assume an October upgrade and the org lands in an earlier wave, you can lose most of the preview window before regression testing is complete.

The other planning milestones are:

The Sandbox Preview Instructions give that 6:00 p.m. cutoff and explain the preview tracks. Salesforce's admin countdown says 5:00 p.m. for the same deadline. An hour early costs nothing; an hour late costs the whole preview window.

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 not permission to raise every pinned API or runtime version in bulk. An API-version change should still follow the same regression process as any other code change.

For most admins, the version number is not the main risk in this release. The more immediate developer issue is the difference between a Winter '27 preview environment and a production org that still runs Summer '26 limits.

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

Profile Filtering is the first test I would run

Once Profile Filtering is enforced, the user who does not have View All Profiles permission sees just their own profile name. The most obvious place to test will be user management. Less obvious places where Profile Filtering can be tested are approval processes, assignments, reports, formulas, Flow, Apex, and custom components that check the profile of another user.

Salesforce does not provide one universal failure mode for all of these use cases. Depending on the specific implementation, some hidden assumption about profiles may lead to unexpected behavior, null values, or no visible issues at all. This is why testing as a System Administrator proves very little.

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 a process fails, do not solve it by handing View All Profiles to everyone. Give it only to roles with a documented need. If the problem is broader than Profile Filtering, trace the affected user's profile, permission sets, role, and record access before changing permissions.

The accessibility updates change how Lightning reflows above 200% zoom

The three other enforced updates change how 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 is not only an accessibility review. A custom component that looked fine at ordinary zoom can overlap a standard control when the surrounding container starts to reflow.

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

Run that check on 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 rises from 6 MB to 10 MB, and the asynchronous limit rises from 12 MB to 25 MB. The increase is welcome. It does not make large collections, attachments, response bodies, or serialized payloads free.

The practical trap is timing. Code can pass in a Winter '27 preview sandbox and fail after deployment to Summer '26 production because production still has the smaller heap. Salesforce provides a temporary nonproduction setting that enforces the Summer '26 heap limit during this mixed-version period.

Winter '27 sandbox → Enforce the Summer '26 Apex heap limit → run Limits.getLimitHeapSize() → repeat the deployment test.

Flow now retries record locks instead of failing with UNABLE_TO_LOCK_ROW

When a Flow hits record lock contention during transaction initialization, Salesforce now waits 10 seconds and retries instead of failing immediately with UNABLE_TO_LOCK_ROW. A transaction that used to fail may now succeed, which is good. It may also run long enough for an external caller to time out, which is not.

That makes transaction duration part of the test result, not just success or failure. Re-run bulk imports, scheduled automation, and mass reassignment, and pay attention to any process where two transactions update the same household, donor, campaign, program, case, or summary record. Check for duplicate downstream work as well as the final status.

Scheduled Flows also get optional dynamic batch sizing. After a CPU, SOQL, or heap limit error, an enabled Flow retries with half the previous batch size and can keep reducing it until records process successfully.

Screen and autolaunched Flows get another optional change: on runtime API 68.0, they can consistently enforce the running user's permissions. Neither option changes every existing Flow automatically. Test the security context, total run time, transaction count, callouts, and fault handling before enabling either one.

One quieter Flow change belongs in the deployment test. Saving an existing auto-layout Flow now stores End elements explicitly in its XML. The business logic has not necessarily changed, but the source-control diff has. Save and retrieve a representative Flow before the first Winter '27 deployment, so reviewers and metadata tooling do not mistake that mechanical change for new logic.

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

After the existing org is safe, Winter '27 has several useful additions. None of them deserves adoption merely because it is new.

Screen Flows can run as mass quick actions. A user can select records in a list view or related list and run one guided process against the selection. That could support controlled bulk stewardship, participant follow-up, or grant-review work. The August 19 PDF says the Flow receives the selected record IDs, but it does not give the selected-record variable name or type. Verify the contract in a Winter '27 org before making it an internal build 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 an HTTP callout that should not reach the live endpoint during a test. This can make regression work much better, but a beta test tool should not become the only evidence that a production deployment is safe.

A few smaller changes are worth checking only if they solve a real problem.

• 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 a partner, participant, board, or reviewer portal. Only after guest and authenticated personas prove that sharing and field-level access still hold.

What does Winter '27 mean for an NPSP org?

This is where the Salesforce naming can send a nonprofit down the wrong path. Winter '27 affects an NPSP org because NPSP runs on the platform, but the release does not contain an NPSP feature. The terms NPSP and Nonprofit Success Pack do not appear in the August 19 PDF. There is no NPSP retirement, migration deadline, or automatic move to Agentforce Nonprofit in these notes.

NPSP is a separate suite of managed packages, and Salesforce has not discontinued it. What has changed is where new licenses go: the Power of Us application now offers approved organizations either ten Agentforce Nonprofit licenses or ten Sales and Service licenses. NPSP is not a license type, so it is not one of those choices; an organization that takes Sales and Service can still install the NPSP packages itself. That is a reason to plan deliberately, not a command to migrate before the organization is ready. If migration is already on the roadmap, treat the move from NPSP to Nonprofit Cloud as a separate architecture project. Winter '27 does not set its timetable.

For an NPSP-only org, the Winter '27 plan is platform regression: 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 relevant product work is Program, Case, and Outcome Management setup, Fundraising, and Grantmaking. If the organization runs both products or is midway through a transition, first document which installed package, object, license, and integration owns each process. The release name does not answer that architecture question for you.

What changes for Agentforce Nonprofit?

The notes say that Nonprofit Cloud is now called Agentforce Nonprofit. That is a product-name transition. It is not a rename of NPSP, and it does not move NPSP data into the newer product.

Availability depends on the org's Nonprofit Cloud products, edition, and add-ons. A feature in the notes is not proof that it is licensed in a particular nonprofit org.

Admins can configure Program Management, Case Management, and Outcome Management through guided steps in Salesforce Go. Treat Salesforce Go as a guided setup entry point; the note does not describe 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.

The overview also announces a Program Participant Portal template with preconfigured Experience Cloud pages for programs, applications, enrollments, benefit assignments and disbursements, and referrals.

What are the Winter '27 Fundraising features?

Fundraising gets two related household features.

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

Second, admins can define formulas for household names and greetings. Salesforce recalculates them when 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 visible checkbox is only the start 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 entries concern credit attribution. If the org is moving from NPSP or running both products, compare the new household behavior with its existing NPSP soft-credit rules. The objects are different, but the organization's recognition policy still has to match.

Create the gift, open the resulting household, verify its relationships and naming, and then confirm hard-credit, soft-credit, and household totals. Run the same scenario through the API. Existing customers should also inspect field-level access and page layouts before adding the new fields.

What changed in Grantmaking?

Grantmaking admins can use Action Plan Templates that target the Application Form Evaluation object for repeatable, multi-stage application evaluations. More importantly, Compliant Data Sharing can restrict each reviewer to assigned evaluation sections through the new AppFormEvalSectionPtcp object.

That second part is the feature to test.

Test as Reviewer A: assigned sections only. Test as Reviewer B: their assigned sections only. Test as process owner: full 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.

The nonprofit overview sounds broader than its detailed notes. Volunteer Management gets no feature note. Outcome Management appears only inside the Salesforce Go setup note, and the Program Participant Portal appears only in the overview. The work with enough detail to plan is concentrated in Fundraising and Grantmaking. In practical terms, this is not a broad new nonprofit-product launch.

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

The integration I 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 belongs to the integration owner, not to an admin guessing from login history during release week.

SOAP login() has two official rules, so check the org control. The Winter '27 note says, without qualification, that every SOAP login() user needs Use Any API Auth and that users without it can no longer authenticate. It has no When section. The current retirement guidance, like the older Summer '26 note, says existing orgs require the permission only when an admin enables the control; newly created orgs enforce it by default.

For an existing org, let the actual control decide. Find Enable SOAP API login() to users with the Use Any API Auth user permission, inventory the identities that genuinely call SOAP login(), and test each one in nonproduction.

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

If enforcement is enabled, assign the permission narrowly to the integration users that need it. Granting it while the control is off creates an unnecessary authentication permission; ignoring it while the control is on can stop SOAP authentication completely.

Old SOAP versions have a later deadline. Versions 31.0 through 64.0 retire in Summer '27, and SOAP login() is unavailable in version 65.0 and later. This is the awkward part: an integration cannot simply move its login() request to 65.0. Inventory the job or vendor tool and give the replacement a named owner. Follow the retirement guidance above as the schedule develops.

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.

Hard-coded instance URLs now have a changing official schedule, but only one sensible fix. The PDF and live Winter '27 note say enforcement was postponed until Spring '27, and that Salesforce enforces it in phases.

For the phases, they point to a separate End-of-Support Schedule. That page puts sandbox enforcement between October 22 and November 5, 2026, and production enforcement between January 12 and March 25, 2027. It also contradicts itself: the table lands 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

Starting August 31, enable this control in a sandbox. Run every affected integration end to end, then confirm the production instance's date in the live schedule. If enforcement happens later, the organization has 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?

This is an inventory, not ten automatic projects. If the nonprofit does not use an affected product, write “not applicable” and move on. Salesforce keeps the dated list on its Active Product & Feature Retirements page.

Only check these additional dates if the org uses the affected configuration:

• September 30 — Marketing Cloud installed-package secrets last rotated before March 25.
• October — the start of Microsoft EWS disablement.
• October 31 — legacy Snowflake shares.
• November 10 — Trialforce domains.

The Winter '27 test plan I would actually use

A release checklist should follow the work in the order it happens. Use real roles and actual operating processes, and write down the result while the preview org still exists.

Before preview testing

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, every privileged operations role, and an admin. List the donation, program, case, grant, report, portal, and approval paths each person must complete.
3. Give every integration an owner. For each connection, record 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.

In the preview sandbox

4. Run the profile test first. Repeat the same approvals, assignments, reports, Flows, formulas, Apex, and custom UI as the three user types. Do not use an admin-only result as proof.
5. Zoom the pages staff cannot avoid. Check them at 200% and 400% with a keyboard as well as a mouse. A visible button is not useful if focus never reaches it.
6. Stress the expensive automation paths. Cover synchronous and asynchronous Apex, scheduled and bulk Flows, and two transactions updating the same record. Re-run relevant Apex with the Summer '26 heap setting; measure Flow duration as well as success.
7. Put representative Flows through deployment. Save and retrieve an auto-layout Flow, inspect the new End-element metadata, and make sure review or normalization tooling handles it. If a Flow moves to runtime 68.0 or a new user context, add a permissions test.
8. 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.
9. Test the nonprofit product that is installed. For NPSP, run critical donation and integration paths. For licensed Agentforce Nonprofit, follow household creation through relationships, naming, credits, totals, and reviewer access. A transition org needs both tests and a documented source of truth.

Before production upgrades

10. Wake up the quiet jobs. In the preview sandbox, run representative monthly, quarterly, and annual automation instead of waiting for its normal date. Assign owners only to retirements and deadlines the org uses; mark the rest not applicable.

If there’s no clear owner for running and documenting this work, address that before testing begins. Whether that means assigning someone internally or bringing in Salesforce support, the important part is making sure the work doesn’t remain unowned going into the release.

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

Summer '26 used API version 67.0; Winter '27 uses 68.0. The more useful difference is the shape of the risk. Summer '26 asked admins to pay close attention to new security defaults and several broad platform changes. Winter '27 is narrower and easier to misread because much of the noise concerns deadlines that moved or updates that were canceled.

For this release, spend the first testing hours on Profile Filtering, accessibility reflow, the mixed-version Apex heap issue, changed Flow timing, and old authentication. Agentforce Nonprofit customers then have a separate decision about Fundraising and Grantmaking. NPSP-only customers do not need to manufacture a product migration from a platform release.

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

If this were my nonprofit org, the order would be simple: remove canceled items from the release plan, confirm the real maintenance date, test profiles and high-zoom pages, find the old integrations, and only then open the new features. That order is less exciting than a “top Winter '27 features” list. It is also much more likely to prevent the Monday-morning problem that release preparation is supposed to avoid.

What Salesforce has not said yet

Three facts still lack published values or dates:

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

Do not put any of these into a committed scope, budget, or deadline without a published retirement date or a written licensing answer.