A connected app and an external client app both let an outside system authenticate into Salesforce. The external client app is the replacement. It is secure by default, splits configuration into global developer settings and local admin policies, and is the only one of the two that can ship in a second generation package. As of Spring '26, Salesforce disables the creation of new connected apps by default, and recommends external client apps in all situations.
Why this choice changed in 2026
For years the connected app was the only way to authenticate an external system into Salesforce. That changed. Salesforce introduced external client apps as the successor framework, and in Spring '26 it stopped letting orgs create new connected apps unless an admin asks for the setting to be turned back on. If you are choosing between the two today, the decision is mostly made for you, and this page explains what actually differs underneath.
What Spring '26 changed
Spring '26 disables the creation of new connected apps by default. The block applies both in Setup and through the Metadata API. Two things it does not do: it does not disable connected apps that already exist, and it does not block a connected app arriving as part of an installed package.
An org that genuinely needs to create a new connected app can have the setting re-enabled by Salesforce Support. That is an exception path, not a supported long term position. Salesforce's own guidance is to use external client apps in all situations and to migrate existing local connected apps across.
Connected app vs external client app compared
| Connected app | External client app | |
|---|---|---|
| Status in 2026 | Creation disabled by default from Spring '26, existing apps keep working | The recommended framework for all new integrations |
| Security posture | Open by default, access is granted then restricted | Secure by default, access is granted explicitly |
| Configuration model | Developer settings and admin policies share one metadata file | Split into global settings owned by the developer and local policies owned by the admin |
| Packaging | Cannot be packaged with second generation packaging, uses a reference model | Works with second generation packaging, which is what AppExchange builds on now |
| Role separation | The framework cannot cleanly separate developer and admin duties | Developers own the OAuth settings, admins own the policies |
| Distribution | Reference based | Local or packaged, only packaged apps clone into sandboxes |
| Typical use | Existing internal integrations already in production | New integrations, ISV packages, system to system automation |
The consumer key and secret on an external client app live in the global settings and are deliberately not packageable, which is what allows one app definition to be distributed without leaking the credentials of the org that built it.
Two terms that often create confusion are Connected App and External Client App. They sound similar. They solve similar problems. Yet they are built for very different scenarios.
Let's break it all down in simple, human terms.
Why App Authentication Matters
Authentication is not just about logging in. It defines:
- Who can access your data
- What data they can access
- How long they can access it
Think of authentication as the gatekeeper to your Salesforce org. Choose the wrong gatekeeper, and either everything becomes slow and risky, or nothing works at all.
The Rise of Secure Integrations
Modern businesses rely on APIs, mobile apps, partner tools, and automation. Salesforce had to evolve beyond username-password logins. That's where OAuth-based apps entered the picture.
What Is a Connected App?
Definition of a Connected App
A Connected App is a Salesforce app framework that enables external applications to integrate with Salesforce using OAuth, while still respecting user-level permissions.
In simple words, a Connected App acts like a trusted middleman between Salesforce and another application, on behalf of a user.
How Connected Apps Work
Connected Apps authenticate users via OAuth. Once authenticated, Salesforce issues an access token tied to:
- A specific user
- A specific app
- Defined permission scopes
Everything the app does depends on what that user is allowed to do in Salesforce.
OAuth Flow in Connected Apps
Common OAuth flows used:
- Authorization Code Flow
- Username-Password Flow
- JWT Bearer Flow
Each flow balances security and convenience differently.
Key Features of Connected Apps
OAuth Scopes
Scopes define what the app can do, such as:
- Read data
- Modify records
- Access APIs
- Refresh tokens
No scope, no access. Simple.
Policies and Permissions
Connected Apps let admins control:
- IP relaxation
- Session timeout
- Token refresh behavior
This makes them ideal for internal governance.
User-Level Access Control
This is the biggest advantage. Even if the app is powerful, it can only do what the logged-in user is allowed to do.
Common Use Cases of Connected Apps
Internal Integrations
Perfect for internal tools where employees log in using Salesforce credentials.
Salesforce-to-Salesforce Connections
When one org talks to another, Connected Apps handle authentication cleanly.
Admin-Controlled Applications
If admins want tight control and audit trails, Connected Apps are the go-to choice.
What Is an External Client App?
Definition of an External Client App
An External Client App is designed for system-to-system communication where no Salesforce user is involved.
It authenticates using client credentials, not human users.
How External Client Apps Work
Instead of asking a user to log in, the app proves its identity using:
- Client ID
- Client Secret
Salesforce then issues a token tied to the app itself.
OAuth Flow in External Client Apps
The most common flow here is:
- Client Credentials Flow
No login screens. No user interaction. Just clean, automated access.
Key Features of External Client Apps
Client Credentials
Authentication is based on the app's identity, not a person.
App-Level Authentication
The app runs in a system context, which makes it predictable and consistent.
Token-Based Access
Tokens are short-lived and tightly scoped, improving security.
Common Use Cases of External Client Apps
Public APIs
When exposing APIs to external systems, this model works best.
Customer-Facing Applications
Mobile apps or portals where Salesforce users should not exist.
Partner Integrations
Ideal for B2B integrations that need stable, automated access.
Connected App vs External Client App: Core Differences
Authentication Model
- Connected App: User-based authentication
- External Client App: App-based authentication
Security and Control
Connected Apps rely on user permissions. External Client Apps rely on app policies.
Scalability
External client apps suit system to system work better because the client credentials flow runs as a dedicated integration user rather than borrowing a logged in person's session.
User Context vs System Context
This is the heart of the difference:
That distinction drives the OAuth flow you pick. A user based integration uses a flow that produces a token tied to a person, so it inherits that person's permissions and stops working when they leave. A system based integration uses the client credentials flow, which runs as a nominated integration user and keeps working regardless of staff changes. Salesforce blocks the username and password flow outright, so it is not an option for either.
- Connected App = "What can this user do?"
- External Client App = "What can this system do?"
Security Considerations
Data Access Control
Connected Apps are safer when user-level auditing is required. External Client Apps are safer for automation with minimal exposure.
Token Expiry and Refresh
Always configure short-lived tokens and rotate secrets regularly.
Compliance and Governance
Connected Apps shine in regulated environments where traceability matters.
Performance and Scalability Comparison
Rate Limits
External Client Apps handle higher throughput more efficiently.
Concurrent Sessions
Connected Apps can struggle if many users authenticate at once.
Enterprise Readiness
Large-scale integrations usually favor External Client Apps.
Which One Should You Choose?
Decision Framework
Ask yourself:
- Is a Salesforce user involved?
- Is this automation or interaction?
- Do I need user-level permissions?
Real-World Scenarios
- An internal employee tool that acts on behalf of the person using it fits the user based model.
- A customer facing mobile app is better served by an external client app.
- A nightly data sync between systems belongs on an external client app with client credentials.
Best Practices for Implementation
Choosing the Right OAuth Flow
Never use username-password flow unless absolutely necessary.
Managing Secrets Securely
Store client secrets in vaults, not code.
Monitoring and Auditing Access
Enable logs, alerts, and token revocation strategies.
Common Mistakes to Avoid
Over-Permissioning Apps
More access does not mean better integration.
Ignoring Token Management
Expired tokens cause silent failures.
Misaligned App Architecture
Choosing the wrong app type leads to security and scaling issues.
Which one to pick
The debate of Connected App vs External Client App is not about which one is better. It is about which one fits your use case.
Migrating from a connected app
Migration is not an in place upgrade. You create the external client app, move the OAuth settings and policies onto it, repoint the integration at the new consumer key and secret, then retire the old connected app once nothing is authenticating against it.
Sequence it so the two run in parallel for a window. Because the credentials change, every client that authenticates has to be updated, and anything you miss fails at the next token refresh rather than immediately. Audit connected app usage in Setup before you start so you know the full list of consumers.
Connected apps still work if you already have them, and Salesforce has not announced a shutdown date for existing ones. But new build should start on external client apps, because that is where the packaging support and the security model are going.
If you are shipping a managed package on AppExchange, the choice is not a preference. Second generation packaging only accepts external client apps.
Frequently asked questions
Can I still create a connected app in Salesforce?
Not by default. From Spring '26 Salesforce turns off the creation of new connected apps in both Setup and the Metadata API. Connected apps that already exist keep working, and one arriving inside an installed package still installs. If you have a genuine need to create a new one, Salesforce Support can re-enable the setting for your org.
Is an external client app the same as a connected app?
No. It is the successor framework and it is built differently. An external client app separates global settings, which the developer owns, from local policies, which the admin owns, and it starts from a secure by default position rather than an open by default one. A connected app keeps both halves in a single metadata file.
Do external client apps work with managed packages?
Yes, and this is the practical reason many ISVs moved. External client apps are supported by second generation packaging. Connected apps cannot be packaged with 2GP, they use an older reference model. If you are building a managed package for AppExchange today, the external client app is the only one of the two that fits.
Should I migrate my existing connected apps?
Salesforce recommends migrating local connected apps to local external client apps. There is no forced deadline announced for existing apps, so this is planned work rather than an emergency. Prioritise anything you are about to package, anything that needs clean developer and admin separation, and anything you were going to rebuild anyway.
Which OAuth flow should an external client app use?
For system to system work use the client credentials flow, which runs as a nominated integration user and does not depend on a person staying employed. For an app acting on behalf of a signed in person, use an authorisation code based flow. The username and password flow is blocked by Salesforce and should not appear in any new design.
What is the difference between a local and a packaged external client app?
A local external client app exists only in the org where it was created and is the right shape for your own internal integrations. A packaged one is distributed inside a second generation package to other orgs. Only packaged external client apps clone into sandboxes when the org is refreshed.
Does switching to an external client app change my credentials?
Yes. The new app has its own consumer key and secret, so migration is not transparent to the systems that authenticate. Every client has to be repointed. Anything you miss keeps working until its current token expires and then fails at refresh, which is why the failures often show up days after the change.
