External Client Apps in Salesforce Spring '26: A Practical Migration Guide

If you're an admin or developer who's been putting off learning about External Client Apps, Spring '26 just made that decision for you. As of the Spring '26 release, Salesforce disables the creation of new Connected Apps by default in every org. You can still flip a setting to create them short term, but the writing is on the wall. External Client Apps (ECAs) are the future, and the sooner you get comfortable with them, the less painful the migration will be down the road.

I've been working through ECA setups for a few clients over the past few months, and I want to share what I've learned. This isn't marketing fluff. It's the stuff I wish someone had told me before I started clicking around Setup trying to figure out why my OAuth flows kept failing.

Why Salesforce Built External Client Apps

Connected Apps have been around for over a decade. They work, but they carry a lot of baggage. If you've ever tried to package a Connected App and distribute it across multiple orgs, you know what I mean. The metadata model is inconsistent, the security controls are scattered, and the packaging story never really came together the way it should have.

ECAs are Salesforce's answer. They use second-generation managed packaging, which is the same modern framework that powers most new Salesforce development work. They're more secure out of the box because they follow a "closed by default" model. That means the app literally cannot do anything in your org until you install it and explicitly grant permission. No more orphaned Connected Apps sitting in Setup that some admin created three years ago and forgot about.

The other big shift is that ECAs make inbound and outbound governance a lot cleaner. You get clearer separation between who's publishing the app, who's installing it, and what the app is allowed to do in each org. For anyone managing integrations across multiple environments, this alone is worth the effort.

If you're still getting up to speed on the terminology around OAuth flows, token exchange, and scopes, I've found the glossary at salesforcedictionary.com useful for quick lookups during setup. It's saved me from going down Wikipedia rabbit holes more than once.

What's Actually Changing in Spring '26

Let me be specific about what's happening, because the messaging from Salesforce has been a little scattered.

Starting with Spring '26, new Connected Apps can no longer be created by default. Existing Connected Apps keep working. They're not deprecated yet, and you don't have to migrate them tomorrow. But Salesforce has made it clear that ECAs are the long-term model, and new feature work is happening on the ECA side.

There's also a separate but related change: as of February 16, 2026, you can no longer send session IDs in outbound messages. You have to use OAuth instead. This affects anyone who was using the old session ID pattern for outbound integrations, and it's worth auditing your org for any remaining references.

One important limitation to know about before you start migrating: ECAs don't support the Username-Password OAuth flow. If you have integrations that depend on it, you're stuck on Connected Apps until you either change your auth flow or Salesforce adds support. Push notifications are also not supported on ECAs yet. So before you plan any migration, check what your existing Connected Apps actually do. You might find you can't migrate some of them at all right now, and that's okay.

How to Create an External Client App

The setup process is similar to Connected Apps but not identical. Here's the basic flow I use:

In Setup, type "External" in Quick Find and click on External Client App Manager. Then click New External Client App. You'll enter a display name and an API name (the API name is what you'll reference in code and metadata, so pick something you won't regret).

Enable OAuth and configure your callback URL. This is the URL that receives the authorization code after a user authenticates. If you're building a server-side integration, this might be an endpoint on your application. For a single-page app, it could be a redirect URI you've registered.

For OAuth scopes, you'll typically want some combination of: api (manage user data via APIs), web (manage user data via web browsers), refresh_token (maintain the session), and lightning (access Lightning apps). Don't just check every box. Grant only what the integration actually needs. This is one of the security wins of ECAs, and it's also just good practice.

Once you save, head to Policies and configure who's allowed to use the app. Setting Permitted Users to "Admin approved users are pre-authorized" is usually what you want for internal integrations, because it forces you to assign a permission set before any user can actually use the app. That way, you control exactly who can authenticate, and you have an audit trail.

The Migration Playbook I Use

If you have more than two or three Connected Apps in your org, don't just start migrating randomly. Get organized first.

Step one is inventory. Go to App Manager in Setup and list every Connected App you have. For each one, figure out: what integration is it for, who owns it, is it still in active use, what OAuth flow does it use, and does it rely on any ECA-unsupported features (like Username-Password or push notifications).

You'll probably find two or three apps that nobody knows about. That's normal. Check the login history for each Connected App to see if anyone has actually authenticated against it in the last 90 days. If not, you might be able to just retire it without migrating.

Step two is prioritize. Start with new integrations. Any new integration work should use ECAs from the start. Then migrate your highest-risk or highest-value apps. Highest-risk means apps with broad scopes or admin-level access. Highest-value means the integrations that drive revenue or support critical business processes.

Step three is the actual migration. For each Connected App, create an equivalent ECA with the same OAuth settings. Update your integration code or configuration to point at the new ECA's client ID and secret. Test thoroughly in a sandbox first. I cannot stress this enough. OAuth errors are miserable to debug in production, and every integration has its own quirks.

Once the ECA is working in production, you can remove or disable the old Connected App. Don't do this in the same deployment window as the ECA rollout. Give yourself a couple of weeks to confirm nothing's broken before you pull the trigger.

Common Pitfalls to Watch For

A few things I've run into that cost me time:

Callback URL mismatches are the top cause of OAuth errors. If your callback URL in the ECA doesn't exactly match what your client sends, authentication fails with a generic error that doesn't tell you why. Double-check the URL, including trailing slashes and HTTPS.

Permission sets matter more than they used to. Because ECAs use a closed-by-default model, forgetting to assign the permission set to the user will produce login errors that look like the auth flow is broken. It's not. It's just that the user isn't permitted to use the app.

Scoped tokens behave differently. If you've been relying on the behavior of the old Connected App token system, test carefully. The way refresh tokens and access tokens interact under the ECA model is slightly different in some edge cases.

If you hit a term you don't recognize during all of this, salesforcedictionary.com is a decent quick reference for OAuth and identity concepts in the Salesforce context. I keep it open in a tab when I'm doing heavy integration work.

What This Means for Your Team

For admins, the biggest shift is that you need to understand ECAs well enough to audit them and grant the right permissions. The "closed by default" model means you'll be involved in every integration decision, which is a good thing, but it does mean more tickets if your team isn't prepared.

For developers, ECAs are the new default. Learn the metadata format, get comfortable with deploying them via SFDX, and update your team's integration templates. The Trailhead modules on External Client Apps are a solid place to start if you want a hands-on walkthrough.

For architects, this is a chance to clean up years of accumulated integration debt. Use the migration as an excuse to document what integrations exist, retire the ones nobody's using, and standardize your patterns going forward. You may not get another opportunity like this for a while.

The Bottom Line

Spring '26 isn't forcing you to migrate all your Connected Apps overnight, but the direction is clear. ECAs are the future, and the earlier you start building muscle memory around them, the smoother the eventual full migration will be. I'd suggest picking one low-risk integration to migrate this month just to go through the process end to end. You'll learn more from one real migration than from reading 10 blog posts (including this one).

If you've already started your ECA migration, I'd love to hear what surprised you. Drop a comment below with what you ran into, what worked, and what you wish you'd known before starting. And if you're just getting started and have a specific question, ask away. I'll try to answer what I can.