Salesforce External Client Apps: A Practical 2026 Guide

If you logged into a sandbox last month and tried to spin up a new Connected App, you probably saw something that made you pause. The button is gone. The setup page nudges you somewhere else. And depending on your org, the path forward isn't immediately obvious.

Welcome to the External Client Apps era. With the Spring '26 release, Salesforce flipped the switch and disabled the creation of new Connected Apps by default across every org. The replacement, External Client Apps (or ECAs, because of course there's an acronym), has actually been around since Winter '24, but most teams ignored it. That grace period is over.

I've been quietly migrating integrations at a few orgs over the last couple of months, and I want to share what's actually involved, where the rough edges are, and how to think about this transition without panicking. If you manage anything that touches Salesforce APIs, this affects you.

Why Salesforce Made the Change

Connected Apps have been around since 2012. They worked, but they carried a lot of baggage. Anyone with the right permission could create one, the metadata model was inconsistent, and packaging behavior had a bunch of quirks that frustrated ISVs. Once an admin shared a consumer secret in Slack by accident, you basically couldn't reset it without breaking everything downstream.

External Client Apps fix most of those issues. They use second-generation managed packaging, which means version control behaves the way you'd expect from any modern dev tool. Policy enforcement is centralized rather than scattered across "OAuth scopes" and "OAuth policies" tabs. And critically, the metadata is cleaner, so you can actually deploy ECAs through CI/CD without hand-editing XML files at midnight.

The Spring '26 announcement isn't a "Connected Apps are dead tomorrow" message. Existing Connected Apps keep working. Apps inside managed packages keep working. But new creation through UI and API is blocked by default, and Salesforce Support has to flip a feature flag if you genuinely need to keep using the old model. That's the kind of friction that tells you where the platform is going.

What Actually Stays the Same

Before you spend a Saturday rewriting all your integrations, let me save you some time. A lot of things don't actually change.

Your existing Connected Apps still authenticate users. Your existing OAuth tokens still work. Your existing API calls still hit the same endpoints. If you have a five-year-old MuleSoft integration humming along nicely, you don't need to drop everything and migrate it this quarter. The platform isn't going to break it.

The OAuth 2.0 flows are also identical. Web Server flow, Client Credentials flow, JWT Bearer, Device Flow, PKCE - all of these still apply to External Client Apps. If your team understands OAuth, the transition is mostly about where you click in Setup, not about learning new authentication concepts.

What does change is the long-term path. Eventually, Salesforce will deprecate Connected Apps fully. We don't know when. But the writing is on the wall, and waiting until you have six months notice to migrate forty integrations is a bad strategy.

Setting Up Your First External Client App

Here's the part that actually matters - how do you create one? The basic flow is similar to Connected Apps but lives in a different Setup location.

Navigate to App Manager, then look for the "New External Client App" button instead of "New Connected App." You'll go through three main configuration sections. The first is Basic Information, which covers the standard name, contact email, and logo. Nothing surprising.

The second section is OAuth Settings. This is where you'll spend most of your time. Enable OAuth, choose your callback URL (HTTPS only, please don't use HTTP even in sandboxes - it'll bite you later), and pick your scopes. The "Full access" scope is convenient but I'd push you toward more specific scopes whenever possible. If your integration only reads accounts and writes tasks, give it api and refresh_token and call it done. Least privilege isn't paranoia, it's good hygiene.

The third section handles Policies. ECAs introduce a clearer split between app-level config and policy enforcement, which is one of the genuine improvements over the old model. You can require admin approval, restrict to specific permission sets, set IP relaxation rules, and define refresh token policies all in one place.

Once you save, copy the Consumer Key and Consumer Secret immediately and store them in your secrets manager. Don't email them. Don't paste them in Slack. I know it sounds obvious, but I've cleaned up after enough security incidents to know it's not.

Migrating Existing Connected Apps

If you're migrating, Salesforce shipped a tool that handles most of the heavy lifting. The Connected App to External Client App migration utility lives in Setup under External Client App Manager. Pick the Connected App you want to migrate, choose whether to do a "local" migration (keeps it in your org) or a packaged migration (for ISV scenarios), and follow the wizard.

A few things to watch for during migration:

Consumer Key preservation. The migration utility lets you keep the existing Consumer Key, which is huge. Your downstream integrations don't need new credentials. If you've ever had to coordinate a credential rotation across twelve different services, you'll appreciate this option.

Profile and permission set assignments. ECAs handle user assignment slightly differently. Verify that your assignment policies still match what you expect after migration. I've seen one case where assignments silently dropped because the Connected App used a deprecated assignment style.

Custom attributes and SAML. If your Connected App used SAML for SSO or had custom attributes for downstream identity providers, test those flows end-to-end before declaring victory. The mapping isn't always one-to-one.

Managed package apps. If the Connected App came from an AppExchange package, you can't migrate it yourself. The publisher needs to ship an ECA version. Reach out to the vendor and ask about their roadmap. Most major ISVs are already shipping ECA versions, but some smaller ones are dragging their feet.

If you're tracking acronyms, this whole space is full of them. ECA, OAuth, JWT, PKCE, SAML - if you're new to integration work and want a single place to look these up, salesforcedictionary.com keeps a clean glossary that's actually useful for cross-checking terminology when reviewing documentation.

Best Practices I've Learned the Hard Way

A few patterns have emerged from doing this enough times.

Document your integrations before you migrate. Build a simple spreadsheet listing every Connected App in your org, what it talks to, who owns it, and what scopes it needs. You'll discover things. Almost every org I've audited had at least one Connected App that nobody could explain. Some of them were active. That's not great.

Use Client Credentials flow for server-to-server. If you have a backend service that needs to act as itself rather than impersonating a user, the Client Credentials flow is the right tool. It avoids the awkward "shared service account" pattern where you have a fake user named "API User" that everyone fights over.

Rotate secrets on a schedule. ECAs make rotation easier than Connected Apps did. Take advantage of that. Pick a quarterly rotation cadence for any high-privilege integration. Build the rotation into your runbook so it's not a heroic effort each time.

Test in a sandbox that mirrors production permissions. I've seen migrations that worked perfectly in dev sandboxes and broke in production because of profile differences. Use a full sandbox if you have one, partial copy if you don't, and verify the actual permission set assignments match.

Don't migrate everything at once. Start with low-risk integrations. Learn the quirks. Build a runbook. Then tackle the customer-facing or revenue-critical ones. The platform isn't forcing a deadline, so don't invent one for yourself.

What's Coming Next

Salesforce hasn't announced a hard deprecation date for Connected Apps. Based on how the platform usually handles these transitions, I'd expect a multi-year runway with progressively stricter defaults. We might see read-only mode for existing Connected Apps in Summer '27 or Winter '27, with full deprecation maybe a release or two after. That's speculation on my part, but it's the pattern Salesforce has used for things like API versions and Lightning Experience.

What is confirmed is that all new platform features built around app integrations are landing on the ECA side first. If you want to use the newest OAuth flow types, the cleanest packaging behavior, or any of the App Management improvements coming in Summer '26, you need ECAs to get there.

The other thing worth flagging is that this aligns with broader industry shifts. TLS certificate lifespans are dropping to 200 days in March 2026, then 100 days in 2027, then 47 days in 2029. Combined with the ECA push, the message is consistent - integrations need to be more disciplined, more rotatable, and more observable than they were five years ago. That's a good direction even if it creates short-term work.

For anyone building or reviewing integrations, having a quick reference for these terms helps a lot. The salesforcedictionary.com glossary is one I keep bookmarked alongside the official Salesforce docs - it's quicker for the "wait, was that JWT or SAML?" moments.

Wrapping Up

External Client Apps aren't a revolution. They're a cleanup. Connected Apps grew organically over a decade, picked up some warts, and the platform team finally got space to redesign the model. The result is more secure, more consistent, and more aligned with how modern integration teams actually work.

If you're staring at a list of forty Connected Apps wondering where to start, my advice is simple. Inventory first, prioritize by risk, migrate in batches, and don't skip the testing. The migration utility is good, but it's not magic, and the integrations that break are always the ones nobody thought to test.

Have you started your ECA migration yet? What surprised you, what worked smoothly, and where did you get stuck? Drop a comment and let's compare notes - the more practical experience we share, the easier this gets for everyone still on the early side of the curve.