Back to Insights
Industry News
12 min readOctober 16, 2026

Salesforce Winter '27 Is in Your Org: What Already Changed, What Retires Next, and How to Find the Integrations That Will Break

Winter '27 is live. Profile filtering is enforced. Refresh tokens expire Nov 4, SOAP login() users need Use Any API Auth by Dec 1, the username-password flow retires Feb 20. Here's the calendar and how to find what breaks.

Tim Owens

Founder & CEO, Wrenk

Share:
Salesforce Winter '27 release and integration compatibility visualization

Short answer: Winter '27 finished rolling out to production on October 9, 2026 *(Salesforce Developers blog)*. Upgraded orgs now enforce Enable Profile Filtering: users see only their own profile name unless they hold View All Profiles. Several authentication changes follow on fixed dates: - Nov 4, 2026: refresh tokens expire after 30 days of inactivity - Nov 30, 2026: OAuth device flow is restricted to local external client apps - Dec 1, 2026: SOAP `login()` users need Use Any API Auth - Feb 20, 2027: the username-password, user-agent and hybrid user-agent flows retire - Summer '27: SOAP `login()` (API 31.0–64.0) retires and connected-app support ends

Integrations break quietly, at login, with nothing in the UI, so build the inventory now.

Last reviewed: 2026-10-16. We'll update this before Nov 4 and Feb 20.


What already changed when your org upgraded

Profile Filtering. Reports, list views, flows, Apex or integrations that show or query *other* users' profile names can behave differently. Test as a standard user in an upgraded sandbox. Admins hold View All Profiles, so testing as an admin proves nothing. Grant View All Profiles only where it's needed, through a permission set.

*Use Any API Auth for SOAP `login()`.** The Salesforce Developers blog says: "Beginning December 1, 2026, every user who authenticates with SOAP API login() needs the Use Any API Auth user permission." Assign it to integration users through a permission set now. Treat it as a stopgap, not a fix. *(Some third-party guides list it as enforced on upgrade. Check Setup → Release Updates in your org.)


Available now, enforced in Spring '27

View Setup Audit Trail permission. When it's enforced, Salesforce auto-grants it to existing View Setup holders. New profiles, permission sets or users need it granted explicitly *(Salesforce Admins blog)*.


The retirement calendar

| Date | What changes | Who it bites | Source | |---|---|---|---| | Nov 4, 2026 | Refresh tokens expire after 30 days idle | Monthly or quarterly jobs | Salesforce Architect Highlights | | Nov 30, 2026 | OAuth device flow restricted to local external client apps | CLI/device-style apps | Salesforce Architect Highlights | | Dec 1, 2026 | Use Any API Auth required for SOAP `login()`; Email Verification Exception removed (only if Support once disabled verification for your org) | Integration users; orgs with that exception | SF Developers blog; SF Admins blog | | Feb 20, 2027 | Username-password, user-agent and hybrid user-agent flows retired | Anything posting `grant_type=password` | Salesforce Architect Highlights | | Spring '27 | View Setup Audit Trail permission enforced; Salesforce-to-Salesforce and cross-org adapter legacy auth | New reviewers; S2S users | SF Admins; Architect Highlights | | Summer '27 | SOAP `login()` in API 31.0–64.0 retires; connected apps support ends | Legacy integrations; every connected app | SF Developers blog; Architect Highlights | | Summer '28 | API 31.0–40.0 calls fail (deprecated Summer '27) | Old API versions | SF Developers blog |

(No single date for phishing-resistant MFA is stated here, because sources conflict. API-only logins are out of scope per Salesforce's FAQ as quoted by others.)


How to find the integrations that will break

  1. **Setup → Release Updates.** Read each card for your org.
  2. **Login History for SOAP `login()`.** Filter for Login Subtype "SOAP API" and API Type SOAP Enterprise/Partner/Tooling. *(Confirm the labels in your org.)*
  3. **Login History for the username-password flow.** Look at Login Type "Remote Access 2.0" with an OAuth username-password subtype. Login History keeps about six months, so rarely run jobs can be missing. Treat what you find as a minimum, not the full list.
  4. **Connected Apps OAuth Usage** in Setup gives a shortlist of apps actually used for OAuth.
  5. **List anything that runs less than monthly** because of the Nov 4 refresh-token change.
  6. **Ask the owners** of middleware, vendor apps, BI tools, data loaders and identity-provider provisioning connectors.

When the flagged integration isn't yours to fix

If Login History points at a vendor or identity-provider connector (for example, user provisioning from an identity provider): 1. Confirm the integration user and app. 2. Give that user Use Any API Auth before Dec 1. This buys time until Summer '27. 3. Ask the vendor in writing which auth it uses, what its OAuth / External Client App option is, and when that's available. 4. Plan an alternative if it has no answer. 5. Put vendor items first in your order of work. 6. Restrict the integration user to API-only and least privilege. See our [field-level security fix](https://www.wrenk.ai/fix/field-level-security).


Inventory template

| Integration | Owner | Vendor-managed? | Integration user | Auth today | API version | Connected app / ECA | Run frequency | Replacement flow | First deadline | Status | |---|---|---|---|---|---|---|---|---|---|---|


What to move to

  • **Server-to-server:** OAuth 2.0 client credentials flow, or JWT bearer (a certificate, no stored password).
  • **User-facing apps:** web-server flow with PKCE.
  • **Device-flow apps:** a local external client app with a localhost callback.
  • **Secrets:** keep them in Named Credentials, and give run-as users least-privilege permission sets.
  • **Don't migrate to a pattern** that's already on a path toward restriction.

Connected apps → External Client Apps

Salesforce says support for connected apps ends by Summer '27. In App Manager, open a connected app and choose Migrate to External Client App. Start with your most critical integrations. Decide the owner, scopes and approvers for each app. Test in a Winter '27 sandbox, never in production.


Test safely

Use a sandbox already on Winter '27. Never start the SOAP `login()` retirement *test run* in production while integrations are unmigrated. It blocks all SOAP `login()` calls for as long as the test runs.


Related: Gemini 2.5 reroute

If you're also using Agentforce or Einstein Studio, note that Salesforce is rerouting Gemini 2.5 models on October 20, 2026. See [Salesforce Is Rerouting Gemini 2.5 on October 20](/insights/salesforce-gemini-2-5-reroute-test-before-october-20) for the testing checklist.


FAQ

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

No. It was postponed to Feb 20, 2027.

Do connected apps stop working in Summer '27?

Support ends then. Salesforce says they continue to work for a while, but plan to migrate.

Do I lose Setup Audit Trail access?

Not if you already hold View Setup. New users will need the new permission from Spring '27.


Not sure where your org stands? Answer three questions in the free health check. It needs no account and no sales call: [Start the free health check →](https://wrenk.ai/free-health-check?utm_source=wrenk_insights&utm_medium=blog&utm_campaign=wrenk-04-winter-27)

Tags:
winter-27
salesforce-release
oauth
soap-api
integration-auth
external-client-apps

Enjoyed this article?

Get more insights on SaaS management, AI automation, and RevOps strategy delivered weekly.