April 1, 2026

Salesforce External Client Apps: The Admin's Guide to Setup, Policies, and OAuth in Spring '26

Connected Apps are out. Here is what Salesforce admins need to know about External Client Apps: setup, OAuth flows, policy controls, and what changed in Spring '26.

You open Setup, navigate to App Manager, and go to create a new Connected App. The button is greyed out. No error message. No explanation. Just greyed out.

This is not a permissions issue, and it is not a bug. It is intentional.

Salesforce blocked the creation of new Connected Apps starting with the Spring '26 release. The replacement is called salesforce external client apps (ECAs), a new model that separates the app definition from OAuth policy control. Understanding that distinction is the whole ballgame.

This post covers what changed and why, how ECAs differ from Connected Apps, step-by-step setup, OAuth flow support, what happens to your existing Connected Apps, and how to audit ECA activity in your org.

What Changed in Spring '26 (and Why Salesforce Did It)

The greyed-out "New Connected App" button is not a UI glitch. It is Salesforce enforcing the new model at the UI layer.

As of Spring '26, you cannot create new Connected Apps. Existing ones continue to work. This is not a hard sunset of the old model, just a wall on new creation.

Why the Change

The core driver is separation of duties. In the old Connected Apps model, a single admin could own both the app definition and the OAuth policy settings. That put a lot of sensitive configuration in one place, under one role.

ECAs split that into two distinct roles:

App Manager (App Owner): Creates and owns the app definition (name, OAuth scopes, callback URL, client credentials).
Admin Policies section: A separate area in Setup where an org admin controls OAuth behavior for that app (permitted users, IP relaxation, refresh token policy).

One person builds the integration. A different person (or the same person with a different hat) controls whether that integration is allowed to run, and under what conditions. That is a meaningful security improvement.

What Is NOT Changing

Despite the "salesforce connected apps deprecated" framing you may see circulating, existing Connected Apps are not broken. You can still view, edit, and use them. Users and service accounts authenticating through existing Connected Apps will not lose access.

What you cannot do is create a new one. Anything net-new goes through External Client Apps.

External Client Apps vs. Connected Apps: What Actually Differs

The salesforce external client app vs connected app question comes up constantly right now, so here is the full comparison.

Dimension	Connected Apps	External Client Apps
Where you create them	Setup > App Manager > New Connected App	Setup > App Manager > New External Client App
Who controls OAuth policies	Same admin who created the app	Separate Admin Policies section in Setup
Supported OAuth flows	Auth Code, Client Credentials, Device, JWT Bearer, Username-Password	Auth Code, Client Credentials, Device, JWT Bearer (Username-Password not available)
Visibility in SetupAuditTrail	Logged under "Connected Apps" section	Logged under "External Client Apps" section
Packaging / ISV support	Available	Available (with updated packaging metadata)

The practical difference shows up most when you have multiple teams. A developer team can build the ECA definition in a sandbox without touching org-wide OAuth policy. The security admin reviews and sets policy in production independently. That workflow was not possible with Connected Apps.

How to Create an External Client App (Step by Step)

This section focuses on what an admin needs to do in Setup. No code required.

Step 1: Navigate to App Manager

Go to Setup > App Manager. In the top right, click New External Client App (this is the button that replaced the greyed-out Connected App option).

Step 2: Fill In the App Definition

You will see a form with these required fields:

App Name: The human-readable label. Choose something descriptive (e.g., "Nightly Data Sync - Warehouse").
API Name: Auto-populated from App Name. This is the unique identifier used in metadata and packages. Edit it if the auto-generated version is unclear.
Contact Email: Used by Salesforce if there are policy issues with the app. Use a team inbox, not a personal address.

Step 3: Configure OAuth Settings

This is where most of the integration-specific work happens.

Callback URL: The URL Salesforce redirects the user to after successful authentication. For web apps, this is your app's OAuth redirect endpoint. For server-to-server flows, some tools use a localhost or placeholder value here.

OAuth Scopes: Select only the scopes your integration actually needs. Common options:

api (Access and manage your data): Read and write access to most standard and custom objects. Use this for integrations that need to query or update records.
full (Full access): Superset of api. Includes chatter and content. Only use if your integration genuinely needs it.
refresh_token (Perform requests at any time): Required if you want the integration to maintain persistent access without requiring users to re-authenticate on a schedule.
openid (Access unique user identifiers): Required for identity and SSO use cases.

Principle of least privilege applies here. If the integration only reads Opportunities, it does not need full.

Step 4: Save the App Definition

Click Save. At this point you have an app definition, but it is not yet configured for production use.

Step 5: Navigate to Admin Policies

This is where the separation of duties becomes tangible. After saving, go to Setup > External Client App Manager and find your app. Open it, then click Admin Policies.

This section is separate from the app definition and controlled independently. This is the part most admins miss.

Step 6: Set the Core Policy Controls

Configure these three settings. Each involves a security tradeoff:

Permitted Users:

All users may self-authorize: Any user in the org can authenticate with this app. Appropriate for broadly used tools (e.g., a company-wide dashboard).
Admin-approved users are pre-authorized: Only users in specific profiles or permission sets can use this app. Use for service accounts and integrations that should not be user-initiated.

The security tradeoff: "All users" is convenient but wide. If credentials leak, any org user could potentially authenticate. Admin-approved narrows the blast radius.

IP Relaxation:

Controls whether users must be on an org-trusted IP range to authenticate.
Enforce IP restrictions: Stricter. Users or service accounts must authenticate from a trusted IP.
Relax IP restrictions with second factor: Allows off-network auth with MFA. Good middle ground for remote teams.

Refresh Token Policy:

Controls when refresh tokens expire.
Immediately expire refresh token: Token is single-use. Most secure. Requires re-authentication frequently.
Expire refresh token if not used for N days/hours: Balances security and user experience. Recommended for most integrations.
Refresh token is valid until revoked: Persistent access. Use only for highly controlled service accounts where you have clear visibility into token usage.

Step 7: Enable and Test

Toggle the app to Enabled in Admin Policies. Test in a sandbox before deploying to production. Confirm the OAuth flow completes and the callback URL is reached.

Most common mistake: Saving the app definition and calling it done. If you skip Admin Policies, the app is in a default permissive state. Go back and set policies explicitly, every time.

Which OAuth Flows Work in External Client Apps (and Which Don't)

This is the section most other posts skip. Here is a clear breakdown for the "salesforce oauth 2.0 authorization code flow external client app" question and its siblings.

Authorization Code Flow

Status: Supported. Recommended.

The standard web OAuth flow. A user initiates authentication, is redirected to Salesforce login, consents, and is redirected back with an authorization code. Your app exchanges the code for an access token.

Use this for: web apps, user-facing integrations, anything where a human authenticates.

Client Credentials Flow

Status: Supported.

Server-to-server authentication without a user context. Your app presents a client ID and client secret to get an access token directly. No user consent step.

Use this for: nightly batch jobs, data pipelines, system integrations that run unattended.

Device Flow

Status: Supported.

Designed for devices or environments that cannot open a browser. The device shows a code; the user goes to a separate browser session to authorize.

Use this for: CLI tools, headless servers, IoT integrations.

Username-Password Flow

Status: Not available in ECAs.

This is intentional, not an oversight. The Username-Password flow skips the OAuth consent step entirely by passing credentials directly. It is a security anti-pattern. Removing it from ECAs forces integrations to use explicit consent-based flows.

If your existing Connected App uses Username-Password flow, you will need to migrate to Client Credentials or Authorization Code flow when you rebuild it as an ECA. This migration is the right move regardless.

JWT Bearer Flow

Status: Available, with prerequisites.

Uses a digital certificate (X.509) to sign an assertion. Salesforce validates the assertion and issues an access token without a user redirect. Requires pre-authorization of the connected user and certificate setup.

Use this for: high-security server-to-server integrations where you want certificate-based trust rather than a client secret.

Decision Guide

Integration type	Use this flow
User logs into a web app	Authorization Code
Nightly batch job, no user context	Client Credentials
CLI tool or headless device	Device
High-security server integration with certificate	JWT Bearer
Credential-passing (legacy pattern)	Not available. Rebuild using Client Credentials.

What Happens to Your Existing Connected Apps

Short answer: nothing, for now. They keep working.

You cannot create new Connected Apps, but you can still view and edit existing ones. Users and service accounts authenticating through them will not lose access. Salesforce has not announced a hard sunset date.

When to Migrate (and When Not To)

There is no automated migration path. Moving a Connected App to an ECA is a manual rebuild:

Document your existing app's settings: scopes, callback URLs, permitted users policy, IP relaxation, token policy.
Create the equivalent ECA in a sandbox. Match the scopes and configure Admin Policies to mirror your current settings.
Update the client application (your integration code or vendor configuration) to use the new Client ID and Secret.
Test thoroughly in sandbox. Confirm the full OAuth flow completes.
Deploy the ECA to production. Keep the old Connected App active during the cutover window.
Monitor for authentication errors. Once stable, you can deprecate the old app.

Key warning on migrate connected app to external client app salesforce: Existing refresh tokens do not transfer. Every user or service account that authenticated through the old Connected App will need to re-authenticate after you cut over to the ECA. Plan for this explicitly, communicate it to users, and schedule it outside a change freeze window.

How AuditForce Fits Here

ECA setup and SetupAuditTrail monitoring are the same problem viewed from different angles. One is prevention, the other is detection.

When an admin connects AuditForce to their Salesforce org, that connection is made through an External Client App using the Authorization Code flow. That event is recorded in SetupAuditTrail with the ECA name, the authenticating user, and a timestamp.

The same is true for every third-party tool that connects to your org via ECA. Every new OAuth connection, every re-authentication, every token revocation: each one generates a SetupAuditTrail entry. AuditForce pulls those entries daily, categorizes them by severity, and surfaces them in your digest.

Practical examples:

A vendor connects a new integration to your org on a Friday afternoon. You see it in your Monday digest.
A service account re-authenticates an ECA at 2am. You see it flagged by severity, not buried in raw logs.
Someone modifies the Admin Policies on an ECA (changing from admin-approved to all users). AuditForce flags it as a high-severity security change.

The goal is not to make you dig through logs. It is to make ECA activity visible without requiring you to remember to look.

AuditForce monitors every OAuth connection in your org through SetupAuditTrail. See which External Client Apps accessed your org and when.

What to Do Now

Three things, in order:

Stop creating new Connected Apps. The button is greyed out anyway, but if you have a process or runbook that references them, update it now.
Build all new integrations as ECAs from the start. Do not look for workarounds. The new model is better, and it is the only model going forward.
Audit your current ECA inventory. Go to Setup > App Manager and filter by type "External Client App." For each one, open Admin Policies and verify: Are the Permitted Users settings intentional? Is the refresh token policy set explicitly, or left at the default? Are the scopes minimal?

If you want ongoing visibility into which ECAs are active in your org and what they are doing, AuditForce surfaces that information automatically from SetupAuditTrail every day. For a broader framework on how to monitor Salesforce org changes, including ECA activity alongside configuration and security changes, see the full monitoring guide.