When people compare External Client vs Connected Apps, they’re usually trying to decide how Salesforce integrations should be built today. For years, connected apps have powered integrations and still exist in many orgs. External client apps are the newer approach, designed to handle packaging, security, and distribution more cleanly.
What Is a Connected App?
A connected app is Salesforce’s original way to let a third-party application access Salesforce data.
It records key details about the external application, including:
- Which authentication protocol it uses, such as OAuth, SAML, or OpenID Connect
- Where the external application runs
- What level of access should it have
Once this information is in place, Salesforce can authenticate users, issue tokens, enforce security rules, and track usage.
You’re probably using connected apps already. The Salesforce mobile app is one example. Any external web or mobile app that connects to Salesforce APIs usually relies on a connected app behind the scenes.
Connected App Use Cases
Teams commonly use connected apps in a few well-defined scenarios.
One is API integration. External systems can read or update Salesforce data, such as syncing orders, customers, or support cases.
In addition, another is identity and single sign-on. Connected apps can act as service providers in SAML-based login flows.
They’re also used to control security. Admins can define exactly which data a third-party app can access, apply IP restrictions, and require multi-factor authentication.
Finally, connected apps are often used to authorize external API gateways, including gateways hosted on MuleSoft’s Anypoint Platform.
What Is an External Client App?
An external client app serves the same purpose as a connected app: it allows a third-party application to integrate securely with Salesforce.
The difference isn’t in what it does, but in how it’s designed.
Salesforce built external client apps to support modern Salesforce development practices.They work cleanly with second-generation packaging, enforce stronger security boundaries, and clearly separate developer setup from admin policy control.
Because of this, Salesforce positions external client apps as the successor to connected apps.
External Client App Use Cases
External client apps are especially useful when integrations need to be reused or distributed.
They’re a strong fit for packaged applications that are installed in multiple Salesforce orgs. They also work well for locally built integrations that follow source-driven development and CI/CD pipelines.
External client apps are designed for situations where developers define how the app works, while admins in each org control how it’s used.
External Client vs Connected Apps: Comparison
|
Connected Apps |
External Client Apps |
| Limited support for second-generation packaging
and often requires workarounds |
Built for 2GP packaging from the start |
|---|---|
| Works with first-generation packages | Does not support 1GP packaging |
| No concept of local vs distributed state | Supports clear distribution states |
| Developer setup and admin policies are handled together | Developer configuration and admin policies are separated |
| No subscriber org association handling | Supports subscriber association and removal |
| Managed through Salesforce Setup | Managed through Salesforce Setup |
| Metadata API access is partial | Full Metadata API support |
| Supports OAuth 2.0 | Relies on OAuth 2.0, but only through secure, approved flows |
| Works with SAML-based authentication | Supports SAML-based login flows |
| Includes OpenID Connect support | Supports OpenID Connect |
| OAuth keys and secrets can be rotated | OAuth keys and secrets can be rotated |
| Trusted IP ranges supported for OAuth web server flow | Trusted IP ranges supported |
| Copied automatically during sandbox refresh | Copied only when packaged |
| Requires API access control configuration | Separate API access control not required |
| Allows custom attributes | Allows custom attributes |
| Includes audit tracking | Includes audit tracking |
| Supports logging | Supports logging |
| Start URLs can be configured | Start URLs can be configured |
| OAuth access policies can be managed | OAuth access policies can be managed |
| IP relaxation policies available | IP relaxation policies available |
| Session policies supported | Session policies supported |
|
Mobile security policies supported |
Mobile security policies supported |
|
Custom handlers supported |
Custom handlers supported |
|
User provisioning supported |
User provisioning not supported |
|
OAuth usage tracking available |
OAuth usage tracking available |
|
Profile-based access supported |
Profile-based access supported |
| Permission sets supported |
Permission sets supported |
| OAuth-based data access controls available |
OAuth-based data access controls available |
| Canvas framework supported |
Canvas framework not supported |
| App and user notifications supported |
App and user notifications supported |
The goal of this External Client vs Connected Apps comparison is to highlight where each option fits best in real Salesforce integrations.
App Creation and Future Direction
Connected apps can still be used, but new creation is restricted starting Spring ’26. Salesforce recommends external client apps for new integrations.
External client apps are fully supported and intended for long-term use.
Packaging and Distribution
Salesforce did not design connected apps for second-generation packaging, so teams rely on workarounds that use first-generation packages and references.
Salesforce designed external client apps specifically for 2GP, which lets teams package, distribute, install, and manage them cleanly across orgs.
Distribution State
Connected apps don’t track whether they’re local or distributed. External client apps introduce a distribution state. An app can be local to one org or packaged for distribution, and Salesforce handles each case differently.
Developer and Admin Responsibilities
In connected apps, developer configuration and admin policies live together. This makes it harder to control behavior once an app is shared.
External client apps separate these roles. Developers define core settings and package them. Subscriber org admins manage access and security policies locally without changing the packaged app.
OAuth Security Handling
Connected apps store OAuth details directly in the app configuration, which creates challenges when teams distribute apps across orgs.
External client apps split OAuth settings into global and local files, and Salesforce keeps sensitive consumer secrets out of packaged components to reduce security risk.
OAuth Flow Support
Connected apps support a wide range of OAuth flows, and some of those flows no longer meet modern security standards.
External client apps take a stricter approach and support OAuth 2.0 only through secure flows, deliberately excluding options like the username-password flow.
Metadata API and Automation
Connected apps expose only limited functionality through the Metadata API.
External client apps support the Metadata API fully, making them easier to manage through automation, source control, and CI/CD pipelines.
Sandbox Behaviour
During a sandbox refresh or clone, Salesforce automatically copies connected apps. External client apps follow a different pattern. Salesforce keeps local apps in the original org and copies only packaged apps to sandboxes.
Feature Coverage
Most security and policy features are available in both:
- OAuth policies
- IP relaxation
- Session and mobile policies
- Permission sets
- Audit and logging
- Notifications
Some features, like Canvas and user provisioning, are only available with connected apps.
When to Choose External Client vs Connected Apps
In many cases, teams still rely on connected apps for existing integrations. For example, organizations often keep them in place for legacy solutions that already run smoothly. Additionally, when a setup depends on Canvas or user provisioning, teams usually choose connected apps as the practical option.
On the other hand, teams tend to prefer external client apps for new work. In particular, they choose them when packaging and distribution come into play. Over time, this approach makes long-term maintenance easier and supports reuse across multiple orgs.
Also Read –Segments in Salesforce Data Cloud
FAQs
1. Do I need to replace all my Connected Apps?
No. If they’re already working, most teams leave them alone. External client apps mainly matter when you’re building something new or packaging an app.
2. Why doesn’t Salesforce allow the username–password OAuth flow for External Client Apps?
That flow depends on storing real user credentials. Salesforce considers it risky and doesn’t allow it for external client apps, even though older connected apps still support it.
3. When would I actually pick an External Client App?
Teams usually hit this point when they reuse an integration, package it, or deploy it across multiple orgs. At that stage, connected apps start to feel awkward.
Conclusion
Connected apps laid the groundwork for Salesforce integrations. External client apps build on that foundation with better security, clearer role separation, and first-class support for modern packaging.
If you’re designing a new integration today, external client apps are the safer and more future-ready choice.
Get a complete Roadmap To Learn Salesforce Admin and Development👇
