Maintask

Posted on Sep 2

Salesforce Winter ’27 Regression Testing: What a Green Sandbox Can Still Miss

#salesforce #nonprofit #salesforcewinter27 #agentforce

A green sandbox test can be completely accurate and still give you the wrong level of confidence.

The Flow completed.

The Apex tests passed.

The page opened.

The integration returned a successful response.

Everything looks ready.

Then production upgrades and a user reports that an approval behaves differently, an integration can no longer authenticate, or code that worked perfectly in the preview sandbox fails against limits production still has.

Nothing necessarily went wrong with the test.

The problem is that the test proved less than the team thought it proved.

That is the interesting part of Salesforce Winter ’27.

The September 2 revision of the release notes also changed the preparation list again. Salesforce now has five Release Updates enforced with Winter ’27, not the four many August checklists still show. The new addition is the SOAP login() permission requirement.

For nonprofit Salesforce teams, this release isn't mainly about chasing the longest possible list of new features. It is about finding the quiet platform changes that can behave differently inside an org with years of Flows, Apex, permissions, integrations, Experience Cloud pages, NPSP packages, and fundraising processes.

This article stays focused on those regression risks.

For the complete release calendar, all five enforced Release Updates, integration deadlines, NPSP impact, Agentforce Nonprofit features, and the broader upgrade checklist, see the Salesforce Winter ’27 guide for nonprofit admins.

The question here is narrower:

What can still go wrong when the sandbox looks green?

Winter ’27 regression testing in one minute

If there isn't time to read the whole article yet, start here.

Winter ’27 area	What a green test can miss	What to test
Profile Filtering	Admin access hides permission differences	Run the same process as real user personas
SOAP `login()`	An old integration user lacks `Use Any API Auth`	Inventory SOAP identities and authenticate end to end
Flow record-lock retries	Salesforce succeeds after the external caller times out	Measure duration, retries, and duplicate behavior
Apex heap limits	Winter ’27 sandbox has more heap than Summer ’26 production	Re-test against the production-era limit
Accessibility reflow	The page loads, but important actions move or become hard to reach	Test critical pages at 200% and 400% zoom
Flow metadata	Git shows XML changes that aren't business-logic changes	Save, retrieve, and review representative Flows
Integrations	Authentication, endpoint, API version, or ownership is unknown	Inventory and test every important connection end to end

Those checks don't replace a complete release test.

They tell you where a successful test can be misleading.

Why Winter ’27 needs regression testing instead of another feature checklist

Release preparation often starts with the release notes and ends with a spreadsheet.

Feature.

Applicable?

Owner.

Tested?

Done.

That works until the most important change isn't really a feature.

Profile Filtering is a good example.

The Salesforce org doesn't suddenly stop working.

A user simply loses visibility into profile information they could previously see.

That difference may matter only when a particular Flow, formula, report, approval, Apex class, or component evaluates another user.

The same is true of the Flow record-lock change.

A transaction that previously failed can now wait and succeed.

That is an improvement.

But if an external system stops waiting before Salesforce finishes, the overall business process can still fail.

Winter ’27 has several changes like this.

The release doesn't necessarily produce a dramatic red error.

It changes an assumption.

And mature Salesforce orgs are full of assumptions.

Failure pattern #1: Everything works because you tested as System Administrator

Winter ’27 enforces Profile Filtering.

A user without the View All Profiles permission can now see only their own profile name.

On paper, that sounds like a straightforward permissions change.

In a real org, the more useful question is:

What business logic assumes that a user can inspect somebody else's profile?

That assumption can hide in more places than expected:

Flows
formulas
Apex
approvals
assignments
reports
custom Lightning components
user selectors
internal admin utilities

Consider a donation-routing Flow.

It checks the owner of an Opportunity, looks at that user's profile, and uses the result to choose a path.

Nothing about the Opportunity changed.

Nothing about the owner changed.

Nothing about the Flow definition necessarily changed.

But the running user's visibility did.

Now test the process while logged in as System Administrator.

Everything works.

That result can be technically correct and operationally useless.

Use a small persona matrix instead

Persona	Useful processes to test
Fundraising user	Donation entry, ownership, reports
Program or operations user	Cross-team automation and approvals
Privileged non-admin	Elevated processes without full admin visibility
System Administrator	Baseline only

Run the same process as each persona.

For a nonprofit org, that can mean:

creating or updating a donation;
changing record ownership;
submitting an approval;
running a report;
triggering assignment logic;
opening a custom component;
completing a Screen Flow.

If something breaks, don't solve the regression by immediately giving View All Profiles to everyone.

First identify why the process depends on that visibility and give the permission only where there is a documented need.

The pitfall isn't Profile Filtering itself

It's treating:

"It worked for me"

as equivalent to:

"It works for the people who actually use it."

If every regression test was run as System Administrator, Profile Filtering hasn't really been tested yet.

Failure pattern #2: The Flow succeeds after the caller has already given up

Anyone who has worked with busy Salesforce automation has probably met this:

UNABLE_TO_LOCK_ROW

Two transactions need the same record.

One holds the lock.

The other can't get it.

Winter ’27 changes part of that behavior for Flow.

When Flow encounters record-lock contention during transaction initialization, Salesforce can now wait 10 seconds and retry instead of immediately failing.

That can turn a failure into a successful transaction.

Good.

But now imagine the caller isn't another Salesforce process.

Imagine it is:

a donation platform;
middleware;
an event-registration system;
an accounting connector;
a custom API client.

A simplified sequence might look like this:

00s  External system sends request
01s  Salesforce starts transaction
02s  Target record is locked
02s  Salesforce waits
10s  External caller reaches its timeout
12s  Salesforce retry succeeds
13s  Salesforce commits
14s  External caller retries the original request

Salesforce says:

SUCCESS

The caller says:

TIMEOUT — RETRYING

Both can be correct.

And now the nonprofit may have a duplicate-processing problem.

This is especially worth testing around records that many transactions can touch:

household Accounts;
donors;
campaigns;
gifts;
program records;
cases;
summary records;
high-volume imports.

Don't measure only success or failure

For high-contention processes, record:

Salesforce result
Total execution time
Caller timeout
Caller retry behavior
Duplicate protection
Downstream side effects

The useful question isn't:

Did Salesforce finish?

It is:

Did the whole process finish once, within the expectations of every system involved?

The Flow passed. Great. Now check whether the caller was still listening when it finished.

Failure pattern #3: An old SOAP integration stops authenticating

This is the important addition in the September 2 release notes.

Salesforce now lists Assign Use Any API Auth Permission for SOAP login() under the Release Updates enforced with Winter ’27.

If an integration authenticates using the SOAP API login() call, the user making that call needs the Use Any API Auth system permission.

That makes this a real Winter ’27 regression test.

Not a future retirement to put on a backlog.

Start by finding the identities that actually use SOAP `login()`

Don't grant the permission to everyone because one integration needs it.

Inventory:

Integration
SOAP version
Salesforce user
Authentication method
Owner
Last successful test

For every identity that genuinely calls SOAP login():

identify the integration user;
assign Use Any API Auth through a narrowly scoped permission set;
test authentication in nonproduction;
run an actual end-to-end transaction.

The Setup path is:

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

There is a separate org-level detail worth knowing.

SOAP login() is disabled by default in orgs created from Winter ’26 onward. That is not the same thing as the new user permission.

The permission doesn't magically enable an org-level authentication method that is otherwise disabled.

The pitfall isn't SOAP itself

It's discovering during release week that nobody knows whether an old vendor job authenticates through SOAP at all.

The oldest integrations deserve the earliest inventory.

Failure pattern #4: The sandbox has a governor limit production doesn't have yet

Winter ’27 increases Apex heap limits.

Synchronous Apex moves from:

6 MB → 10 MB

Asynchronous Apex moves from:

12 MB → 25 MB

That is genuinely useful for code working with large collections, files, API payloads, serialization, or async processing.

The regression problem appears during the mixed-version window.

A preview sandbox can already be running Winter ’27 while production is still on Summer ’26.

That means this can happen:

Winter ’27 preview sandbox

Heap used: 8.3 MB
Heap limit: 10 MB
Result: PASS

And then:

Summer ’26 production

Heap required: 8.3 MB
Heap limit: 6 MB
Result: FAIL

Nothing is wrong with the sandbox.

It simply answered a different question.

The sandbox proved:

This code fits inside Winter ’27.

The deployment team needed to know:

Does this code fit inside production today?

Check the active limit

Apex already exposes it:

System.debug('Heap used:  ' + Limits.getHeapSize());
System.debug('Heap limit: ' + Limits.getLimitHeapSize());

For a reusable check:

public class HeapCheck {
    public static void logCurrentUsage() {
        Integer used = Limits.getHeapSize();
        Integer limitSize = Limits.getLimitHeapSize();

        System.debug(
            'Heap usage: ' + used + ' / ' + limitSize
        );
    }
}

Winter ’27 nonproduction orgs also provide the Enforce the Summer ’26 Apex heap limit setting.

The September 2 notes clarify that it remains available in Winter ’27 nonproduction orgs throughout the release, including sandboxes, Developer Edition orgs, and scratch orgs.

Use it while production is still on the previous release.

In Spring ’27, the higher limits apply globally regardless of this setting.

Which code deserves another look?

Start with code processing:

large JSON responses;
files and attachments;
generated documents;
large maps or lists;
serialized objects;
Batch Apex;
Queueables;
integration payloads.

The higher limit is extra room.

It shouldn't redefine "safe to deploy" before production receives the same room.

Failure pattern #5: The UI works until someone zooms to 400%

Three of the five Release Updates enforced with Winter ’27 concern accessibility and Lightning reflow above 200% zoom.

This is easy to file under:

Accessibility testing.

That's correct, but incomplete.

When standard Salesforce components reflow differently, the custom components around them can move too.

The page can remain technically functional while the task becomes harder to complete.

Salesforce calls out areas including:

page headers;
modal windows;
date pickers;
popovers;
bottom utility bars;
record headers;
cards;
docked containers;
menus;
panels.

A nonprofit shouldn't test a random Account page just because it's convenient.

Test the pages people cannot avoid:

gift entry;
program management;
case management;
grant review;
reports;
quick actions;
Experience Cloud portals.

A useful test is intentionally simple

200% zoom
↓
400% zoom
↓
Keyboard navigation
↓
Mouse navigation

Then ask:

Can the primary action still be reached?
Does keyboard focus make sense?
Are labels still clear?
Can modal buttons be reached?
Do custom components overlap standard Salesforce UI?
Can the user actually finish the task?

The last question matters most.

A page that technically renders isn't necessarily a page that still works for the user.

Failure pattern #6: Git shows a Flow change nobody intentionally made

This one probably won't cause an outage.

It can still waste a surprising amount of engineering time.

Winter ’27 changes how Flow Builder stores End elements for auto-layout Flows.

Saving an existing auto-layout Flow now stores End elements explicitly in the XML.

So a normal workflow can look like:

sf project retrieve start --metadata "Flow:Donation_Intake"
git diff

And Git suddenly reports changes.

The developer didn't intentionally add business logic.

The admin doesn't remember changing the end of the Flow.

The XML still changed.

All three statements can be true.

Calibrate the deployment process before the first real change

Take one representative auto-layout Flow:

save it in the Winter ’27 sandbox;
retrieve it;
run the diff;
identify the expected End-element changes;
make sure reviewers know what the new metadata looks like.

If the team uses CI/CD, metadata normalization, automated review, or Flow-comparison tooling, run those too.

A metadata diff and a behavioral diff are not the same thing.

Knowing which one you're looking at makes the first Winter ’27 deployment much less mysterious.

Two optional Flow changes deserve separate tests

Not everything in Winter ’27 changes existing Flows automatically.

That distinction matters.

Running-user permissions

Screen and autolaunched Flows on runtime API 68.0 can opt into more consistent enforcement of the running user's permissions.

This does not automatically change the security context of every existing Flow.

If the option is enabled, regression-test:

the actual user permissions;
record access;
fault handling;
total runtime;
callouts;
any subflows or actions involved.

Don't combine a runtime-version change, a new security context, and unrelated Flow edits into one deployment if they can be tested separately.

Dynamic batch sizing

Scheduled Flows can also use dynamic batch sizing.

If Salesforce hits certain CPU, SOQL, or heap-limit errors, processing can retry with a smaller batch.

That can turn a failing scheduled job into a successful one.

But, again, success isn't the only metric.

A Flow that finishes after splitting work into more transactions may have different:

total runtime;
callout behavior;
downstream load;
transaction counts.

If dynamic batch sizing solves a real limit problem, great.

Measure what changed around that success.

Failure pattern #7: The integration nobody owns becomes the release risk

The newest Salesforce integration is usually not the one worth worrying about.

Someone remembers the new one.

It has a Jira ticket.

Probably documentation.

Definitely a person who worked on it.

The more interesting integration is the job that has run quietly for four years.

Maybe it:

imports donations;
pushes data to accounting;
synchronizes an email platform;
creates backups;
sends files to another system;
subscribes to a platform event.

Nobody touches it because it works.

Eventually that becomes:

Nobody knows why it works.

Build the boring table

"Boring" is a compliment here.

Integration	User	Auth	API	Endpoint	Owner	Last test
Donation platform	Integration user	OAuth	Known	My Domain	Fundraising Ops	Aug 2026
Accounting sync	Finance user	OAuth	Known	My Domain	Finance	Aug 2026
Legacy export	?	?	?	?	?	?

The third row is the useful one.

For every connection, confirm:

application or vendor;
authentication flow;
API version;
endpoint;
integration user;
monitoring;
owner;
last successful test;
replacement deadline, if one exists.

And Winter ’27 gives several concrete reasons to do this now.

Don't confuse February 2027 OAuth work with upgrade weekend

The OAuth 2.0 username-password flow is not retired when the org upgrades to Winter ’27.

Salesforce moved that retirement to February 20, 2027.

The OAuth user-agent and hybrid user-agent flows now retire on the same date.

If an integration still uses one of those flows, that's real technical debt.

Give it:

an owner;
a replacement design;
a test environment;
a migration date.

But don't confuse a February 2027 remediation project with a September or October 2026 production-upgrade regression test.

Different deadline.

Different workstream.

Don't wait for a hard-coded instance URL to break

Old instance-specific Salesforce URLs are another integration problem worth finding before enforcement does it for you.

Search:

middleware
scripts
CI/CD
Named Credentials
vendor configuration
custom settings
environment variables

for stale instance-specific Salesforce hosts.

Where appropriate, move integrations to the org's My Domain login URL.

A useful sandbox control is:

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

Enable the control in a sandbox and run affected integrations end to end.

The current Salesforce schedule places sandbox enforcement between October 22 and November 5, 2026, and production enforcement in phases between January 12 and March 25, 2027.

The surrounding Salesforce documentation has shifted more than once.

The practical solution hasn't.

Don't wait for enforcement to discover the hostname was hard-coded.

Device Flow has its own November deadline

Device Flow also doesn't belong on the Winter ’27 production-upgrade weekend checklist unless the org actually uses it.

Its important date is November 30, 2026.

After that, Device Flow becomes restricted to eligible local External Client Apps using a localhost callback.

If the org uses that authentication pattern, identify the affected Connected Apps and plan the appropriate External Client App design.

Again:

real work, different date.

Standard-volume platform events deserve special attention

Standard-volume platform events retire on December 15, 2026.

After that date, publishing and subscribing stop working.

Winter ’27 adds a migration path to high-volume platform events, but publishing pauses during the migration.

That means this is maintenance-window work, not something to click during a busy fundraising afternoon.

After migrating, retest every dependent:

Flow;
Apex trigger;
Streaming API client;
integration.

For an established nonprofit org, this is exactly the kind of feature that can sit underneath an old integration nobody thinks about until it stops.

One Winter ’27 project you may be able to remove completely

Earlier Winter ’27 checklists often included Adopt Authorized Email Domains.

Salesforce canceled that Release Update.

It has been replaced by Maintain Your Email Verification Exception, enforced on December 1, 2026.

The replacement is much narrower.

It appears only in orgs where Salesforce Support previously disabled user email verification for a domain.

Check:

Setup
→ Release Updates
→ Maintain Your Email Verification Exception

If it appears, configure the authorized domain and test users and return addresses.

If it doesn't appear, there is no generic Winter ’27 email-domain project for that org.

Release plans should get smaller when Salesforce removes work.

Not just bigger every time somebody publishes another checklist.

For the current deadline table—including which items were canceled, postponed, or moved outside the upgrade window—the full Winter ’27 release guide tracks the broader timeline.

Use nonprofit-shaped test data, not clean demo records

A brand-new Contact and a $10 Opportunity can prove that Salesforce saves a record.

It does not prove that the nonprofit's real operating model survived the release.

Production is messier.

Useful regression scenarios may include:

One-time gift
Recurring gift
Multi-payment pledge
Household with multiple contacts
Organization donor
Soft credit
High-volume donation import
Program enrollment
Grant workflow
Experience Cloud user
Integration transaction

Not every nonprofit needs every scenario.

The point is to use data shapes that actually exercise:

sharing;
relationships;
automation;
rollups;
integrations;
user permissions;
reporting.

If several donations can update the same household during a campaign, test that.

If accounting sync only runs after a particular Opportunity change, test that.

If a portal user has very different permissions from staff, test as the portal user.

Production data has edge cases. Regression data needs them too.

What should an NPSP team actually test?

This is where release coverage can easily create unnecessary work.

Winter ’27 affects an NPSP org because NPSP runs on Salesforce.

The platform changes matter.

But Winter ’27 does not announce:

NPSP retirement;
an NPSP migration deadline;
an automatic migration;
a forced move to Agentforce Nonprofit.

The September 2 release notes do not change that.

So for an NPSP-only org, the useful question is not:

How quickly do we migrate because Winter ’27 arrived?

It is:

Does the Salesforce environment we operate today still work correctly after Winter ’27?

Test:

donation paths;
household processing;
recurring-gift automation;
Profile Filtering;
Apex;
Flow;
high-zoom pages;
Experience Cloud;
installed packages;
payment integrations;
accounting integrations;
email integrations;
backup or ETL jobs.

If an NPSP-to-Agentforce Nonprofit migration is already on the roadmap, that is valid work.

It deserves its own architecture, data, integration, and change-management plan.

Winter ’27 doesn't set that timetable.

Agentforce Nonprofit teams have a different second test

Salesforce now refers to Nonprofit Cloud as Agentforce Nonprofit.

That is a product-name transition.

It is not a rename of NPSP and doesn't move NPSP data into the newer platform.

For organizations already using Agentforce Nonprofit, Winter ’27 has product-specific work in areas such as Program, Case, and Outcome Management setup, Fundraising, and Grantmaking.

But the order still matters.

First:

prove that the existing system survived the release.

Then:

evaluate the new functionality the org is actually licensed to use.

For Fundraising, one useful regression path is:

Gift
→ Donor
→ Household
→ Relationships
→ Naming
→ Hard / soft credit
→ Household totals

Winter ’27 adds automatic household creation and household naming functionality for eligible Agentforce Nonprofit orgs with the required add-on.

Don't stop at confirming that a household record exists.

Check:

the right household;
the right relationships;
naming and greetings;
hard credit;
soft credit;
household totals;
API behavior if gifts enter through an integration.

For Grantmaking, Compliant Data Sharing deserves persona-based testing:

Reviewer A → assigned sections only
Reviewer B → their assigned sections only
Process owner → full evaluation

Once again, security should be tested as the user who is supposed to see less.

The complete object, field, licensing, NPSP, and Agentforce Nonprofit breakdown is in the Salesforce Winter ’27 guide for nonprofit admins.

One more automatic change worth knowing about: Agentforce Platform

The September 2 notes also add a platform change that is easy to miss if you're only reading the nonprofit section.

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 early September.

That doesn't mean users suddenly have a live agent.

Permissions and activation still matter.

But an admin may find Agentforce Builder available without having deliberately enabled the platform.

So treat this as a permissions check, not an AI emergency.

If the org isn't planning to use Agentforce yet:

review who has relevant permissions;
confirm whether Einstein generative AI is enabled;
make sure no agent has been activated unintentionally.

The presence of the platform and the presence of an active production agent are not the same thing.

A 45-minute Winter ’27 regression pass

A complete regression cycle obviously takes longer than 45 minutes.

But 45 minutes can expose where the next few hours should go.

0–10 minutes: users and permissions

[ ] Choose one critical nonprofit process
[ ] Run it as an ordinary user
[ ] Repeat it as a privileged non-admin
[ ] Run it as admin
[ ] Check any logic that reads another user's profile
[ ] Record differences instead of immediately widening permissions

10–15 minutes: SOAP authentication

[ ] Identify any job or vendor that uses SOAP login()
[ ] Confirm the integration user
[ ] Confirm Use Any API Auth
[ ] Authenticate in nonproduction
[ ] Run a real end-to-end transaction

15–25 minutes: Flow and Apex

[ ] Run a process likely to encounter record contention
[ ] Measure Flow duration, not only final status
[ ] Check caller timeout and retry behavior
[ ] Check for duplicate downstream work
[ ] Check Limits.getLimitHeapSize()
[ ] Re-test relevant Apex under the Summer ’26 limit while production is still there

25–30 minutes: UI

[ ] Open a critical page at 200% zoom
[ ] Repeat at 400%
[ ] Navigate with a keyboard
[ ] Check custom components beside standard Salesforce UI
[ ] Confirm the task can actually be completed

30–35 minutes: metadata

[ ] Save one existing auto-layout Flow
[ ] Retrieve it
[ ] Run git diff
[ ] Identify expected End-element changes
[ ] Make sure reviewers understand the new metadata

35–45 minutes: integrations

[ ] List active connections
[ ] Confirm authentication method
[ ] Confirm API version
[ ] Confirm endpoint
[ ] Confirm integration user
[ ] Name an owner
[ ] Check for instance-specific URLs
[ ] Run one real end-to-end transaction

Forty-five minutes won't make an org release-ready.

It can tell you where the real risk is.

That is usually much more useful than spending those forty-five minutes reading another "Top Winter ’27 Features" roundup.

A green sandbox is evidence, not proof

Most Winter ’27 problems won't come from forgetting one headline feature.

They'll come from testing the right thing in the wrong context.

Testing Profile Filtering as admin.

Testing SOAP without the integration user that actually uses it.

Testing Salesforce without the external caller.

Testing Winter ’27 heap limits for a Summer ’26 production deployment.

Testing a page only at default zoom.

Reviewing a metadata diff without knowing serialization changed.

Testing a perfect $10 donation instead of the data shape that puts pressure on the org.

Testing an integration without knowing who owns it.

Each gap looks small.

Together, they explain why a green preview sandbox doesn't automatically mean release-ready.

A useful regression plan isn't trying to prove that everything in Salesforce works.

That would be impossible.

It is trying to prove something narrower:

The processes this organization cannot afford to lose still work for the real users, with representative data, through the real integrations.

If production upgrade weekend becomes boring after that, the testing did its job.