Salesforce is evolving its approach to application integrations with the introduction of External Client Apps (ECAs), marking an important shift in how businesses connect external applications with their Salesforce environments.ย
With the Spring ’26 release, Salesforce has disabled the creation of new Connected Apps by default across all organizations, both through the user interface and APIs. While existing Connected Apps continue to function, External Client Apps are now the recommended approach for building new integrations.ย
This change is more than a platform update. It reflects Salesforce’s focus on stronger security, better access management, and a more structured integration framework.ย
For businesses relying on Salesforce integrations, understanding this transition is essential to maintaining operational continuity and preparing for future platform changes.ย
What Has Changed with Salesforce Connected Apps in Spring ’26?ย
Connected Apps have traditionally enabled external applications to communicate securely with Salesforce through authentication and authorisation protocols such as OAuth, SAML and OpenID Connect.ย
However, Salesforce is gradually moving away from this traditional framework.ย
What this means in practice:ย
- Existing Connected Apps: Continue functioning without disruption and remain editable, installable and deletable.ย
- New Integrations: Must use External Client Apps for Salesforce CLI, middleware, CI/CD and third-party tools.ย
- Temporary Exception: New Connected App creation requires Salesforce Support approval and admin enablement.ย
- Future Direction: Salesforce is moving towards replacing Connected Apps with External Client Apps.ย
What Are External Client Apps?ย
External Client Apps are Salesforce’s next-generation framework for managing integrations between Salesforce and external applications.ย
They provide similar authentication and authorisation capabilities to Connected Apps but introduce a more structured approach to configuration, security and application management.ย
Some of their key advantages include:ย
Stronger Security by Defaultย
External Client Apps follow a closed-by-default security model. Administrators must explicitly approve access before an application can connect to Salesforce. This provides better control over which applications can access organisational data.ย
Separate Developer and Administrator Controlsย
ECAs separate application settings from security policies. Developers can configure OAuth settings, callback URLs and authentication flows, while administrators manage user access, IP restrictions and session policies.ย
Better Packaging and Deploymentย
External Client Apps support second-generation managed packaging (2GP), allowing businesses and developers to distribute applications more efficiently.ย
Improved Metadata Managementย
Their separate settings and policy metadata make it easier to manage configurations through source control and CI/CD pipelines.ย
Together, these capabilities offer businesses a more organised and manageable integration framework.ย
Connected Apps vs External Client Apps: Key Differences
Although both frameworks support Salesforce integrations, there are important differences businesses should understand.
|
Capability |
Connected App |
External Client App |
|
Create new in Spring ’26 and later |
Only after Support enables it |
Yes (default path) |
|
OAuth Web Server, User-Agent, Refresh Token flows |
Yes |
Yes |
|
OAuth JWT Bearer, Client Credentials, Device, Token Exchange flows |
Yes |
Yes |
|
OAuth Username-Password flow |
Yes (not recommended) |
No |
|
OAuth SAML Bearer Assertion flow |
Yes |
No |
|
SAML and OpenID Connect single sign-on |
Yes |
Yes |
|
Default security posture |
Open until restricted (API Access Control available) |
Closed until allowed |
|
Settings vs policies |
One definition |
Separate: developer settings, admin policies |
|
Packaging |
1GP and 2GP (2GP needs manual steps) |
2GP only; local or packaged |
|
Copied on sandbox clone or refresh |
Yes |
Only packaged ECAs |
|
Canvas apps, mobile PIN, push notifications, user provisioning |
Yes |
Historically no; Salesforce is closing these gaps release by release, so check your current release notes |
|
Custom Apex handler for app launch |
Yes |
No |
|
Restrict by profile or permission set |
Yes |
Yes (permission sets recommended) |
|
Rotate consumer key and secret |
Yes |
Yes |
|
One-click migration available |
Source |
Target (one-way) |
Sources: Salesforce developer documentation and vendor migration guides listed at the end.
How to Create an External Client App in Salesforce
This walkthrough sets up the most common new case: middleware that calls Salesforce APIs with the OAuth 2.0 Client Credentials flow, with no user logging in.
Before you start: your user needs the Create, Edit, and Delete External Client Apps permission, and you should have a dedicated integration user with an API-only permission set.
Step 1 โ Start a new External Client App
Go to Setup โ App Manager and click New External Client App.
Step 2 โ Fill in Basic Information and OAuth settings
- Enter the External Client App Name; the API Name fills in automatically.
- Add a Contact Email and a short description.
- Set Distribution State to Local for an app used only in this org, or Packaged if it will ship in a 2GP managed package.
- Under API (Enable OAuth Settings), tick Enable OAuth, enter a Callback URL, and move the scopes you need, typically Manage user data via APIs (api) and, if refresh tokens are used, Perform requests at any time (refresh_token, offline_access).
Step 3 โ Enable the flow and set securityย
Under Flow Enablement, tick Enable Client Credentials Flow. Leave the other flows off unless you need them. In Security, keep the secret required for the Web Server and Refresh Token flows and keep PKCE on for supported flows. Click Create.ย
Step 4 โ Set the policies (admin)ย
Open the app from Setup โ External Client Apps โ External Client App Manager and edit the Policies tab:ย
- Permitted Users: Admin approved users are pre-authorized.ย
- Select Permission Sets: add the integration permission set (prefer permission sets over profiles).ย
- IP Relaxation: Enforce IP restrictions if your middleware has fixed IPs.ย
- Client Credentials Flow โ Run As: the integration user whose permissions the app inherits.ย
- Refresh token and session timeout: as short as your integration allows.ย
Step 5 โ Get the consumer key and secretย
On the Settings tab, click Consumer Key and Secret, complete identity verification, and store both values in your middleware secret store, never in source control. New apps can take up to about 10 minutes to become active, so wait before your first test call.ย
Step 6 โ Test and monitorย
Request a token from https://YOUR-DOMAIN.my.salesforce.com/services/oauth2/token with grant_type=client_credentials, call one API, then confirm the login under Setup โ Login History for the integration user.ย
How to Migrate Existing Connected Apps to External Client Appsย
Salesforce provides a built-in migration option that allows eligible Connected Apps to be converted into External Client Apps.ย
However, this migration is a one-way process. Once completed, the new External Client App cannot be converted back into a Connected App.ย
Step 1: Review Existing Connected Appsย
Identify the Connected Apps currently in use and check their authentication flows, dependencies and third-party integrations.ย
Applications using unsupported flows, such as Username-Password, cannot be migrated without redesigning their authentication approach.ย
Step 2: Check Compatibilityย
Confirm that the authentication flow is supported by External Client Apps. Also, check whether the third-party tools and vendors connected to the application support ECAs.ย
Step 3: Perform the Migrationย
Navigate to Setup โ App Manager, open the eligible Connected App and select Migrate to External Client App.ย
Step 4 โ Verify Credentialsย
- A new External Client App is created from the connected app’s configuration.ย
- The original connected app stays visible in App Manager as a read-only entry; all further changes happen in the ECA.ย
- The ECA can’t be converted back to a connected app.ย
- Credentials: vendor guides differ on whether the consumer key and secret carry over or are regenerated. Open the new ECA’s Consumer Key and Secret, compare them, and update every system that uses them before you call the migration done.ย
- At least one vendor guide reports that deleting the new ECA reactivates the original connected app with its settings intact; treat that as a rollback to verify in a sandbox, not a guarantee.ย
Step 5 โ Test & Controlย
Run each integration once, confirm Setup โ Login History shows logins through the new app, watch error logs for a few days, then remove what is no longer needed.ย
Common Challenges Businesses Should Prepare Forย
Most failed migrations come from the same seven issues, and all of them are cheap to catch in a sandbox.ย
Trapย | What goes wrongย | How to avoid itย |
Sandbox refreshย | Local ECAs are not copied when a sandbox is cloned or refreshed; only packaged ECAs areย | Keep ECA metadata in source control and redeploy it after each refreshย |
Username-password flowย | ECAs don’t support it, so the integration breaks or can’t migrateย | Move to Client Credentials (server-to-server) or JWT Bearer before migratingย |
SAML Bearer Assertion flowย | Not available in ECAsย | Redesign to JWT Bearer or Token Exchangeย |
Third-party toolsย | Some products still require a connected app (one data connector’s docs say its Pardot reader doesn’t support ECAs)ย | Check each vendor’s ECA support before migrating its appย |
Credentials after migrationย | Integrations keep the old key and secret and start failingย | Compare keys after migration and update every consumer in the same change windowย |
Activation delayย | First calls fail right after creationย | Allow up to about 10 minutes before testingย |
Profiles everywhereย | Access tied to profiles is hard to auditย | Assign access through permission sets; profiles are supported mainly for migrationย |
Building a Practical Migration Strategyย
Moving to External Client Apps should be treated as a planned technical initiative rather than a simple configuration change.ย
Organisations can approach the transition through the following steps:
- Inventory: Identify all active Connected Apps, their owners, authentication methods and dependent systems.ย
- Evaluate: Decide whether each application should be retired, redesigned, migrated or temporarily retained.ย
- Prepare: Set up dedicated integration users, review permissions and organise ECA metadata in source control.ย
- Test: Rebuild or migrate applications in a sandbox and validate their end-to-end functionality.ย
- Deploy: Move approved configurations to production during a planned change window.ย
- Monitor: Review login activity, integration logs and authentication errors after deployment.ย
- Document: Maintain records of application ownership, authentication flows, access policies and credential rotation schedules.ย
Audit checklistย
- โ Every connected app has a named owner and a decision (retire, redesign, vendor, migrate)ย
- โ No integration still uses the username-password flowย
- โ Integration users use permission sets, not profiles, for accessย
- โ ECA metadata is in source control and redeployed after sandbox refreshesย
- โ Consumer secrets are stored in a vault and have a rotation dateย
- โ Third-party vendors have confirmed ECA supportย
- โ Login History shows the new apps in use before old ones are removedย
Real-world example: a partner portal designed in 2026ย
On a recent Experience Cloud partner portal design for an industrial manufacturer, every inbound integration became an ECA from day one, and two connections didn’t need one at all.ย
Connectionย | Directionย | What we usedย | Whyย |
ERP middleware upserting customers, assets and ordersย | Into Salesforceย | ECA, Client Credentials flow, dedicated integration userย | Server-to-server, no user login; run-as user limits accessย |
CI/CD pipeline deploying metadataย | Into Salesforceย | ECA, JWT Bearer flowย | Certificate-based, no stored passwordย |
Single sign-on from the portal into partner apps (spare parts catalogue, training)ย | Salesforce as identity providerย | ECA with SAML or OpenID Connectย | Salesforce authenticates the user for the other appย |
Partner login through the company identity providerย | Salesforce as service providerย | SAML single sign-on settings, not an ECAย | The external IdP authenticates; Salesforce only trusts itย |
Pump-selection engine called from Apexย | Out of Salesforceย | Named Credential and External Credential, not an ECAย | ECAs govern apps calling into Salesforce, not callouts going outย |
Conclusionย
Salesforce’s transition from Connected Apps to External Client Apps represents an important step towards more secure, structured and manageable integrations.ย
Although existing Connected Apps continue to operate, businesses should not postpone reviewing their integration environments. Understanding authentication compatibility, strengthening access controls and testing migration procedures will be essential to preparing for the change.ย
By adopting External Client Apps for new integrations and developing a clear migration strategy for existing applications, organisations can build a more secure and scalable Salesforce integration environment.ย
Frequently Asked Questions (FAQs)
Will my existing connected apps stop working?
Not today. Existing connected apps keep working and can still be edited, installed, and deleted. Salesforce’s direction is to replace them, so plan the move rather than wait for a deadline.
Can I still create a connected app if I really need one?
Only if Salesforce Customer Support enables the org permission; then an admin can turn on Allow creation of connected apps in External Client App Settings. Treat this as a short-term bridge.
Does Salesforce CLI need a connected app?
The CLI prefers an ECA. Salesforce’s CLI guide keeps connected-app instructions only until the requirement for certain sandbox and scratch-org scenarios is removed.
What replaces the username password flow?
Client Credentials for server-to-server integrations, or JWT Bearer where you want certificate-based authentication for a specific user.
Why did my ECA disappear after a sandbox refreshed?
Local ECAs aren’t copied on refresh; only packaged ones are. Redeploy local ECAs from source control after each refresh.
Do I need an ECA for Named Credentials and Apex callouts?
No. ECAs control apps that call into Salesforce. Outbound callouts use Named Credentials and External Credentials.
Can I go back after migrating?
No. The converter is one-way; the connected app remains only as a read-only entry.
