--- title: "Salesforce External Client Apps vs. Connected Apps: What Changed in Spring ’26" description: "Understand why Salesforce now recommends External Client Apps for new integrations and how they differ from existing Connected Apps." published: 2026-07-22 modified: 2026-07-22 author: "Neurobase Research" canonical: https://neurobase.dev/articles/salesforce-external-client-apps-vs-connected-apps topics: - Salesforce - External Client Apps - Connected Apps - OAuth - Spring 26 --- # Salesforce External Client Apps vs. Connected Apps: What Changed in Spring ’26 A practical comparison of Salesforce External Client Apps and Connected Apps, including Spring ’26 creation changes, configuration ownership, OAuth choices, and migration guidance. If you have integrated anything with Salesforce in the last decade, you probably know the ritual: open Setup, create a Connected App, enable OAuth, choose scopes, retrieve the consumer key, and wait an oddly suspenseful number of minutes for the configuration to become usable. In Spring ’26, that default changed. Salesforce restricted the creation of new Connected Apps and now recommends External Client Apps for new integrations. Existing Connected Apps can continue working, so this is not a “drop everything and migrate by lunch” emergency. It is a change in the path forward—and it matters for every new dashboard, middleware service, mobile app, or AI connector you build. External Client Apps, or ECAs, are not merely Connected Apps wearing a new label. They reorganize who controls an integration’s settings, improve how configuration participates in modern development workflows, and begin from a more deliberately closed security posture. Let’s make the difference concrete. > **Visual placeholder:** Opening slide with the familiar Connected App setup screen sliding left and the External Client App Manager screen sliding in from the right. Caption: “Existing apps still work. New integrations have a new default.” ## First: what is either kind of app doing? Neither a Connected App nor an External Client App is usually “the application” your users interact with. It is Salesforce’s representation of an external integration. It tells Salesforce things such as: - Which OAuth flows the integration may use - Which callback URLs are valid - Which scopes it can request - How users are approved - How tokens should be handled - Which security policies apply The external dashboard running on Azure, the mobile application on a phone, or Claude connecting through MCP is the client. The Salesforce app configuration establishes the trust relationship. That distinction prevents a common misunderstanding: deleting your frontend does not automatically delete its Salesforce authorization configuration, and changing a callback URL in code does not update Salesforce. The two sides must agree. ## Why Salesforce introduced External Client Apps Connected Apps grew into a large and capable integration mechanism, but their configuration model mixes concerns that belong to different people. A software developer might define an OAuth flow, callback URL, and required scopes. A Salesforce administrator should decide which users may authorize the integration, how long tokens live, and what local security policies apply. Those decisions change at different times and travel through different processes. External Client Apps more clearly separate **developer-controlled settings** from **admin-controlled policies**. That matters when an integration is packaged or deployed across environments. The developer-owned definition can move through source control and deployment tooling, while each Salesforce org retains authority over its local access policy. Salesforce also describes ECAs as closed by default. An app is not simply available everywhere because its definition exists somewhere; it must be explicitly created, installed, or otherwise allowed in the target org according to its distribution model. In plain English: the integration definition can travel, but trust is still granted locally. > **Visual placeholder:** Two-column diagram. “Developer-controlled” contains flows, callback URLs, and scopes. “Admin-controlled” contains permitted users, profiles/permission sets, token policy, and local access. ## What changed in Spring ’26 Starting with Spring ’26, Salesforce disabled the ability to create new Connected Apps by default. Existing Connected Apps continue to function. Organizations that have a specific reason to create another one can contact Salesforce Support, but Salesforce recommends ECAs for new integrations and migration planning. That leads to three practical rules: 1. **Do not panic-migrate a healthy existing integration merely because the season changed.** Inventory it, understand it, and plan deliberately. 2. **Use an External Client App when starting a new integration.** Most new tutorials that still begin with “click New Connected App” are teaching the old default. 3. **Treat migration as security and release work, not a rename.** Consumer credentials, callbacks, policies, user assignments, and token behavior all deserve testing. > **Visual placeholder:** Decision tree. “Existing Connected App working?” → Yes: inventory and plan. “New integration?” → Create ECA. “Special legacy requirement?” → Evaluate support path. ## A side-by-side mental model Here is the comparison I find most useful: | Question | Connected App | External Client App | |---|---|---| | Is it still supported? | Existing apps continue to work | Yes; recommended for new integrations | | Can most orgs create a new one by default? | No, creation is restricted as of Spring ’26 | Yes, subject to permissions | | Security posture | Powerful legacy model with many settings | Designed around a closed-by-default model | | Configuration ownership | Developer and admin concerns are less cleanly separated | Developer settings and subscriber policies are explicitly separated | | Modern deployment workflow | Some metadata support, with historical limitations | Designed for metadata-driven development and packaging | | Good choice for a new OAuth integration? | Generally no | Yes | The important word is **model**. The OAuth standards underneath are familiar: authorization code, PKCE, client credentials, JWT bearer, refresh tokens, scopes, and callbacks. ECAs change how Salesforce represents and governs the client, not the basic reason OAuth exists. ## Creating a local External Client App For an integration used only in one Salesforce org, the setup flow is roughly: 1. Open **Setup**. 2. Find **External Client App Manager**. 3. Create a new External Client App. 4. Choose a local distribution state when the app is specific to this org. 5. Enable OAuth settings. 6. Add the exact callback URL used by the client. 7. Select the minimum required OAuth scopes. 8. Enable only the OAuth flows the client actually uses. 9. Create the app. 10. Configure its policies and permitted users. 11. Retrieve the consumer key—and secret only if the chosen flow requires one. The user interface separates settings and policies, so expect to visit more than one tab. Creating the ECA definition is not the same as finishing its access policy. Also expect propagation time. A newly created or changed OAuth client may not authenticate immediately. Waiting a few minutes is irritating but preferable to “fixing” five unrelated settings during propagation and losing track of which change mattered. > **Visual placeholder:** Screenshot walkthrough of External Client App Manager. Use numbered callouts for Basic Information, OAuth settings, callback URL, scopes, flow enablement, and Policies. Blur the consumer key and all org-specific values. ## Choose the flow before choosing the boxes Salesforce offers several OAuth flows because integrations have different identities. An interactive web dashboard commonly uses Authorization Code with PKCE so each employee signs in and Salesforce issues a token representing that user. A background service with no interactive user may use client credentials or JWT bearer, operating as a configured integration identity. That can be appropriate for controlled automation, but it creates a different audit and permission model. An MCP client connecting to Salesforce Hosted MCP uses an ECA with the callback and scopes required for that MCP client. Salesforce explicitly notes that Connected Apps cannot be used for Hosted MCP authentication. Do not enable every flow “for flexibility.” Each enabled flow is another supported path into the integration and another thing an auditor, administrator, or future maintainer must understand. ## Scope selection is not a wish list OAuth scopes are the outer boundary of what a token may request. Select the smallest set that supports the actual use case. A read-only external dashboard generally needs API access and identity-related scopes, plus refresh-token access if the application maintains a longer-lived server session. It does not need broad administrative scopes. A Salesforce Hosted MCP connection requires the MCP-specific scope documented for that service. Scopes are only one part of the authorization story. The signed-in user’s Salesforce permissions still matter in a user-delegated flow. That is a feature: the same dashboard can respect existing record and field access instead of inventing a parallel entitlement system. ## What about existing Connected Apps? Start with an inventory rather than a migration sprint. For each app, document: - Owner and business purpose - Active users or integration identity - OAuth flows and callbacks - Requested scopes - Permitted-user policy - Token and session policy - Last observed use - Production dependencies - Rotation and revocation process You will probably discover three categories: healthy integrations worth migrating carefully, unused apps worth retiring, and mystery apps nobody wants to touch. The third category is not a reason to ignore the inventory; it is the reason the inventory is valuable. When you migrate, use a test environment and plan for parallel validation. Confirm sign-in, token refresh, user access, API behavior, logout or revocation, monitoring, and rollback. Do not expose consumer secrets in screenshots, deployment logs, or work items. ## The opportunity hidden inside the change Platform transitions are annoying when they invalidate a memorized sequence of clicks. They are useful when they force us to revisit old assumptions. External Client Apps provide a good reason to ask: - Does this integration still need all of its scopes? - Is it acting as the right identity? - Can administrators tell who is allowed to use it? - Is its configuration in source control? - Can we revoke it without an archaeological expedition? The headline is that Connected App creation is restricted. The more useful story is that Salesforce integrations now have a cleaner forward model—one that separates the software definition from the organization’s decision to trust it. That is a change worth understanding before the next OAuth callback starts failing at 4:55 on a Friday. ## References - [Salesforce: The Developer’s Guide to the Spring ’26 Release](https://developer.salesforce.com/blogs/2026/01/developers-guide-to-the-spring-26-release) - [Salesforce: Secure Your Org with External Client Apps](https://developer.salesforce.com/blogs/2025/01/secure-your-org-with-external-client-apps) - [Salesforce: Create an External Client App](https://developer.salesforce.com/docs/platform/mobile-sdk/guide/eca-create.html) - [Salesforce: Set Up Your Org for Hosted MCP Servers](https://developer.salesforce.com/docs/platform/hosted-mcp-servers/guide/setup-overview.html)