Salesforce’s Spring ’27 release is still a few months away, but some of the changes that matter most to organizations are already scheduled for enforcement. If your business relies on Salesforce integrations, older authentication methods, or custom workflows, now would be a good time to find out what might stop working.

Why I’m Looking at Spring ’27 Before Spring

I’ve always found it interesting how little attention integrations receive when they’re working properly.

Someone builds a connection between Salesforce and another application. The team tests it, signs off, and eventually forgets about it. Years later, employees are still relying on that connection without necessarily knowing how it works.

From a Customer Success perspective, I understand why.

When I’m preparing for a client meeting, I care about having the latest account information, project updates, and outstanding issues in front of me. I spend more time in Salesforce than I care to admit, but I don’t normally think about the authentication methods responsible for bringing information into the system.

I just expect the information to be there.

And that’s where release readiness becomes important.

Salesforce’s Spring ’27 release includes security and integration changes that could affect how organizations authenticate applications, share records, and maintain custom functionality.

Some of these changes have already been announced through Salesforce’s Winter ’27 release updates, with enforcement dates coming late winter to early spring.

The Salesforce Release Updates documentation provides the technical details and enforcement schedules.

I wouldn’t recommend waiting until the release weekend to review them.

The concern isn’t necessarily that Salesforce is introducing unreasonable requirements. Most of these changes are intended to strengthen security or retire older functionality.

What concerns me more is whether organizations know which parts of their operations depend on the functionality being retired.

1. The OAuth Changes Are Where I’d Start

If I had to pick one update to focus on for Spring ’27, it’s the deprecation of older OAuth authentication methods.

On February 20, 2027, Salesforce will retire the OAuth username-password flow for connected apps.

The user-agent and hybrid user-agent flows will also be retired on that date.

These authentication methods have been around for years, and some organizations may still have integrations using them.

That doesn’t necessarily mean the integrations are poorly designed. They may have been implemented when those approaches made sense at the time they were released.

But Salesforce is moving toward more secure authentication methods, and applications that continue relying on the retired flows could stop authenticating after enforcement.

Imagine a company that uses an external application to create or update Salesforce records.

The integration has been running quietly for several years. Nobody has touched it because there hasn’t been a reason to.

Then the authentication method stops being supported.

The external application may still be working. Salesforce may still be working. But the connection between them no longer works.

Depending on the integration, the pinch may not be felt immediately by employees.

They might find out about the problem when a customer record is missing, an opportunity doesn’t update or a report has incomplete information.

Salesforce recommends migrating the affected applications to supported alternatives such as the OAuth web-server flow with PKCE or the client credentials flow, depending on the integration.

Its OAuth username-password retirement advisory explains how administrators can identify affected applications through Login History and test replacement authentication methods.

I’d want the Salesforce team to begin there.

Find out which applications are connecting to the organization, how they’re authenticating, and who owns them.

I’d also include integrations managed by third-party vendors.

Just because an application came from an established provider doesn’t mean the organization should assume the migration has already been handled.

Someone needs to confirm it.

2. Some Authentication Deadlines Arrive Even Earlier

One reason I wouldn’t treat this as a Spring-only project is that Salesforce has scheduled other changes for November and December 2026.

The OAuth device flow restrictions are scheduled for November 30.

Salesforce is restricting that flow to qualifying local external client applications using localhost callback URLs. Existing connected apps that rely on the device flow may need to migrate to external client apps.

There’s also a December 1 requirement affecting the SOAP API login() operation.

Affected users will need the Use Any API Auth permission to continue authenticating through that method.

For an organization with a relatively modern Salesforce environment, these changes may have little impact.

For another company, particularly one with older integrations or custom scripts, they could require immediate attention.

I wouldn’t suggest giving every integration user broader permissions just to avoid an authentication problem.

I’d first want to understand why the application still uses that method.

If it’s a legacy integration that the organization intends to replace, there may be a reasonable short-term approach while the migration is completed.

But if the application supports an important revenue process, I’d rather see the team establish a sustainable authentication method than continue adding exceptions.

Security changes sometimes expose technical decisions that organizations haven’t revisited in years.

That’s not necessarily a bad thing.

The problem is discovering those decisions only after the business process stops working.

3. Salesforce Connect and Cross-Org Integrations Need Attention

Another area I’d examine is how information moves between Salesforce environments.

Some organizations use Salesforce Connect to access information from another system or Salesforce org.

Others still rely on the older Salesforce-to-Salesforce functionality.

These integrations can be especially critical for organizations that have grown through acquisitions, have multiple business units or have multiple Salesforce environments.

Salesforce is retiring legacy password and OAuth authentication methods for the Salesforce Connect cross-org adapter in Spring ’27.

Affected configurations need to move to named credentials.

The legacy Salesforce-to-Salesforce product is also scheduled for retirement.

I can imagine this creating additional work for organizations that haven’t revisited their cross-org architecture in some time.

For example, a company has one Salesforce org for sales processes and another for information for another team.

Employees may be used to certain records, not knowing that a legacy integration makes it possible.

A change in connection can affect more than just the technical team doing the maintenance.

Sales might lose sight of information they have depended on in the past. Customer-facing teams may need to request updates manually. Reports that combine information from different environments might become incomplete.

I’d like to know the business purpose of each connection before I select a replacement.

Salesforce has discovered newer ways of integrating and sharing data but that doesn’t mean that every organization should move to the same solution.

The right architecture depends on how the information is used, how frequently it changes, and which system should remain responsible for maintaining it.

Sometimes the difficult part isn’t building the replacement connection.

It’s getting the organization to agree on which information needs to move between systems in the first place.

4. Security Improvements Can Affect Existing Customizations

Security updates are generally a good thing.

But I would not expect an improvement to Salesforce’s security model to be invisible to all employees.

Spring ’27 changes impact guest user access and custom components.

One update is more granular controls for hiding personal information fields from guest users.

This is important for organizations that have public-facing Salesforce experiences, especially when customers or prospects are using forms and portals.

Another update removes non-public system fields from custom object data returned from Aura action responses.

If a custom Lightning component depends on those internal fields, it may stop behaving as expected.

These aren’t necessarily changes that RevOps leaders need to configure themselves.

But they should know whether the organization has business processes depending on the affected components.

I’ve worked with enough client-facing systems to know that an issue with a form can become frustrating very quickly.

A customer submits information, expects someone to follow up, and hears nothing.

Internally, the team may assume the customer never completed the form.

The actual problem could be that a component stopped processing information correctly.

That’s why I’d want someone to test the complete experience, not just whether the page still loads.

Can a customer submit the form? Does the record appear in Salesforce? Does the appropriate employee receive the information?

A successful technical deployment should still produce the business outcome the organization expects.

5. Review Automation That Depends on Record Access

Salesforce is also altering how some sharing recalculations work.

Some sharing updates will be processed asynchronously, so custom automation shouldn’t always assume access changes have been completed immediately.

Organizations with complex sharing rules should look more closely at this.

Think of an automation that alters a user’s group membership and then immediately does something else based on the new access.

If the process assumes that Salesforce has already recalculated sharing, then the next action may return an unexpected result.

This is the sort of issue that may not appear during a basic smoke test.

I’d want administrators and developers to review Flows and Apex code that depend on role changes, group membership, or record-sharing updates.

Then I’d test the affected processes using realistic user permissions.

That last part matters.

An administrator may be able to complete a process successfully because they have access to almost everything.

A sales representative or Customer Success Manager may encounter a different result.

I would also use the review to identify automation that has become unnecessarily complicated.

In our Winter ’27 release analysis, we discussed how Salesforce environments can accumulate overlapping automations over time.

Someone builds a Flow to solve a problem. Another person adds functionality months later. Eventually, nobody wants to change anything because they’re unsure what else might break.

A new release won’t solve that problem for the organization.

But preparing for one can provide a good reason to finally review those dependencies.

6. Don’t Forget the API Connections Nobody Talks About

Authentication is only one part of integration readiness.

Salesforce has also announced phased enforcement affecting API requests that use incorrect instance URLs.

The production enforcement schedule begins in January 2027.

Organizations should review integrations that rely on outdated instance-specific endpoints and verify that they use supported URLs.

I’d include API versions in that conversation as well.

Some organizations have integrations built years ago that continue using older API versions.

That doesn’t automatically mean they’re about to fail during Spring ’27. Different API retirements have different schedules.

Still, I’d want to know which versions are being used and whether there is a plan to maintain compatibility.

One thing I’ve learned from working with business systems is that documentation doesn’t always keep pace with implementation.

The person who originally configured an integration may have moved to another role or left the company.

The application continues working, so nobody asks questions.

Then a release introduces a change, and the team has to investigate something it hasn’t examined in years.

I’d rather identify those dependencies while everything is still working.

It gives the organization time to decide whether an integration needs updating, replacing, or perhaps retiring altogether.

Not every old integration is still providing meaningful value.

Sometimes the release review reveals that the business is maintaining a connection nobody really needs anymore.

7. Test the Revenue Process, Not Just the Integration

This is probably where I’d want Revenue Operations to become more involved.

An administrator can confirm that an integration authenticates successfully.

A developer can verify that an API request returns the expected response.

Both are necessary.

But neither necessarily proves that the business process works from beginning to end.

Think about what happens after a sales representative closes an opportunity.

Salesforce may trigger a handoff to Customer Success, create implementation tasks, update billing information, or notify the delivery team, depending on the organization.

The opportunity may be marked Closed Won, but there is still work to be done before the customer receives what was promised.

Now imagine one of those integrations stops working after a security update.

Sales sees the opportunity as completed.

Customer Success doesn’t receive the handoff.

The customer assumes the project is moving forward, while the internal team is still trying to figure out why the information never arrived.

That situation is more than an integration problem.

It’s a customer experience problem.

In our article on Salesforce opportunity management best practices, we discussed why maintaining accurate CRM information matters beyond the sales forecast.

The same thinking applies here.

I would identify the business processes that rely on the integrations impacted by Spring ’27 and test those business processes end to end.

For Sales, that could mean opportunity updates, quote approvals or lead assignments.

Customer Success, my people, would be account hand offs, customer information and implementation workflows.

Finance may need to validate billing information, contract details, or reporting dependencies.

I wouldn’t ask every department to test every Salesforce feature.

I’d ask them to identify the activities they cannot afford to have interrupted.

That’s a more useful starting point.

8. Someone Needs to Own What Happens After the Release

I’ve always found that technology issues become harder to resolve when several teams are involved but nobody has clear ownership.

An integration fails.

The Salesforce administrator checks the configuration. The vendor says its application is running. The business team reports that records are missing.

Everyone is investigating a different part of the problem.

Meanwhile, employees are trying to continue their work.

This is where I think RevOps can help establish a clearer operating model.

For each critical integration, I’d want to know who maintains the technical connection, who owns the business process, and who validates that the information is correct.

Those responsibilities may belong to different teams.

The Salesforce administrator might manage the integration configuration, while Customer Success owns the account handoff process.

Finance might be responsible for confirming that billing records match what was agreed with the customer.

I’d also want the organization to establish how it will detect failures.

Some problems are obvious. An employee receives an error message and reports it.

Others are less visible.

An integration might stop updating a field or not sync some records but continue to sync others.

The issue might remain unnoticed until somebody prepares a report or needs the information for a customer meeting.

For me, that’s one of the bigger risks.

An obvious failure usually gets attention.

Incomplete information can continue influencing business decisions before anyone realizes something is wrong.

What I’d Prioritize Before Spring ’27

I wouldn’t recommend treating every release update as equally urgent.

I would start with the ones with known enforcement dates that could break existing integrations.

These are Salesforce’s published schedules as of November 2026. Teams should confirm the current enforcement dates in their own Release Updates page, since Salesforce can postpone or revise scheduled changes.

I would start by identifying which of these actually apply to the organization.

Then I’d involve the people responsible for the affected business processes.

There’s no reason to ask Customer Success to test an integration it never uses. But if that integration supports account handoffs, the team should absolutely be involved.

I’d also document the expected result of each test.

Not just whether the integration connects, but whether the right information reaches the right system and the right person.

My Take on Salesforce Spring ’27

What interests me about Spring ’27 isn’t a new interface or another AI feature.

It’s the reminder that the systems businesses rely on need maintenance even when employees don’t notice anything wrong.

We spend a lot of time discussing Salesforce implementations, new capabilities, and ways to improve CRM adoption.

Those conversations matter.

But there’s also value in making sure the technology an organization already owns continues doing its job.

An authentication method that worked for years may no longer meet Salesforce’s security requirements.

A custom component may depend on behavior the platform is changing.

An integration may still be running, but nobody remembers who owns it.

These aren’t particularly exciting topics for a leadership presentation.

They’re still important.

As someone who relies on Salesforce information when working with clients, I would rather know that the records I’m looking at are complete and accurate than discover another feature I can enable.

And from a RevOps standpoint, I think that should be part of the release-readiness conversation.

Salesforce administrators and developers should lead the technical assessment. Security teams should review authentication and access controls.

Revenue Operations should help identify the processes that matter to the business and make sure those processes continue working after the changes take effect.

I wouldn’t measure readiness by how many release updates an organization has reviewed.

I’d measure it by whether the team knows which changes affect its environment, has tested the important workflows, and understands what to do if something fails.

Spring ’27 is still ahead of us.

For organizations with older integrations or heavily customized Salesforce environments, that remaining time is worth using.

Is Your Salesforce Environment Ready for Spring ’27?

These Salesforce security and integration changes are more than just a technical configuration change. They could disrupt the information and workflows that Sales, Customer Success, Finance and other teams depend on.

Revenue Ops LLC works with organizations to audit their Salesforce environments, identify integration risks, improve governance, and prepare for changes to the platform while ensuring business continuity.