External Client App Manager
External Client App Manager is the Setup-area page in Salesforce where admins manage External Client Apps, the modern OAuth-integrated application records that replaced the older Connected App framework for newly registered apps.
Definition
External Client App Manager is the Setup-area page in Salesforce where admins manage External Client Apps, the modern OAuth-integrated application records that replaced the older Connected App framework for newly registered apps. External Client Apps are OAuth 2.0 client identities that external systems use to authenticate against Salesforce, with scopes, policies, and certificate metadata managed through a Setup UI separate from the legacy Connected App Manager.
External Client Apps were introduced in 2024 as the strategic direction for OAuth-protected integrations. They split the App definition (the client identity, secrets, scopes) from the policy configuration (refresh-token behavior, IP restrictions, session policies) into two separate metadata records: ExternalClientApp and ExternalClientAppOauthSettings. The split is what makes External Client Apps work cleanly with Salesforce DX, source control, and packaged deployment patterns that Connected Apps struggled with.
How External Client App Manager separates the OAuth identity from the runtime policy
External Client App versus Connected App
Both serve the same purpose: register an OAuth 2.0 client that can authenticate against Salesforce. The differences are structural. Connected Apps are a single metadata blob containing identity, scopes, and policy. External Client Apps split into two records, which makes deployment and security configuration cleaner. Connected Apps are still supported and not deprecated yet, but Salesforce documentation marks them as legacy for new integrations. New ISV packages, customer integrations, and OAuth-based connectors should default to External Client Apps.
The ExternalClientApp metadata record
The ExternalClientApp record holds the OAuth client identity: name, contact email, logo URL, the OAuth Consumer Key (client_id) and Consumer Secret (client_secret), the requested OAuth scopes, and the callback URLs for redirect-based flows. This record is the identity portion; it does not control how the resulting tokens behave at runtime. Multiple ExternalClientAppOauthSettings records can attach to one ExternalClientApp, letting one client identity have different policies per environment.
The ExternalClientAppOauthSettings metadata record
The settings record holds runtime policy: refresh token behavior (refresh tokens valid until revoked, valid for a set period, immediately expire), IP restrictions (relax, enforce, custom IP ranges), session policy (high-assurance, multi-factor, none), and refresh token rotation rules. Separating settings from the App means an admin can change policy without re-issuing the consumer key, and policy can deploy through pipelines separate from app definition. This is the cleanest improvement over Connected Apps for ops teams.
Supported OAuth flows
External Client Apps support the standard OAuth flows: Authorization Code (with PKCE), Client Credentials, JWT Bearer, Refresh Token, and Device Authorization. Each flow is enabled per-app via scope configuration. The most common flows for modern integrations are Authorization Code with PKCE for user-facing apps and Client Credentials or JWT Bearer for server-to-server. The Username-Password flow is supported but flagged for deprecation; Salesforce strongly discourages new integrations from using it.
Per-user and admin-approved access
Admins control whether users have to individually approve the External Client App on first login or whether an admin pre-approves it for a profile or permission set. Admin-approved access skips the user consent screen and is the common pattern for internal integrations. User-approved access requires each user to click through a consent screen, which is the standard pattern for third-party apps from the AppExchange. The policy is set on ExternalClientAppOauthSettings and inherits to all environments deploying that settings record.
Deployment via Salesforce DX
Both metadata records (ExternalClientApp and ExternalClientAppOauthSettings) deploy cleanly via Metadata API and Salesforce DX. The consumer secret does not deploy in clear text; it is referenced as a metadata token and resolved at runtime against the target org. This is a sharp improvement over Connected Apps where deployment workflows had to side-channel the secret separately. For ISVs, External Client Apps package and install reliably across customer orgs.
Migration path from Connected Apps
There is no auto-migrate from Connected App to External Client App. The two coexist; a Connected App keeps working while you build the External Client App equivalent. Migration steps: create the External Client App with the same scopes, point the integration's redirect URI at the new client_id, deploy, test, then deprecate the Connected App. Most teams run both side by side for a release cycle, then retire the Connected App once traffic has shifted. Salesforce has not announced a sunset date for Connected Apps but new features ship to External Client Apps first.
Registering and configuring an External Client App
External Client App setup happens in two Setup pages: External Client App Manager (the app identity) and OAuth Settings configuration (the runtime policy). Most production integrations need both.
- Open External Client App Manager
Setup, Quick Find, External Client App Manager. The list shows existing External Client Apps. Click New External Client App to start. Connected Apps are a separate area; do not confuse the two.
- Define the App
Enter Name, API Name (lower-case-with-underscores), Contact Email, and a logo URL. Enable OAuth Settings. Configure the callback URL (the post-auth redirect destination), the OAuth scopes (Full Access, API, Refresh Token, custom), and the consumer key visibility.
- Configure OAuth Settings
Click into the OAuth Settings section. Set refresh token behavior, IP relaxation, session policy, and high-assurance requirement. These map to ExternalClientAppOauthSettings; they can be reconfigured later without re-issuing the consumer key.
- Grant access via profile or permission set
Edit the External Client App, navigate to Profiles or Permission Sets, assign the app to the right user audience. Without this, users cannot complete OAuth flows even if the app is otherwise correctly configured.
- Capture the credentials
The OAuth Consumer Key and Consumer Secret are visible in the App detail page. Copy both into your secrets manager or external integration config; the secret is masked after the initial reveal and you cannot retrieve it later, only regenerate.
Authorization Code (with PKCE), Client Credentials, JWT Bearer, Refresh Token, Device Authorization, Username-Password (legacy). Pick per integration type.
Refresh until revoked (long-lived sessions), expires after N days, immediately expire (no refresh). Pick based on how often the user should reauthenticate.
Enforce IP restrictions, relax for OAuth callouts, or relax for both. Relaxing breaks the org-wide IP restrictions for this app, useful for cloud-hosted integrations on dynamic IPs.
Require MFA at token issuance, require MFA only for refresh, no requirement. Pick to match the data sensitivity the app accesses.
- The Consumer Secret is revealed once at creation and never again. Capture it immediately or regenerate when needed.
- External Client Apps and Connected Apps are separate Setup areas. The legacy Connected App Manager is still in Setup for older integrations.
- Profile or permission set assignment is required for users to complete OAuth flows. Without it, users hit a generic auth failure with no clear cause.
- IP relaxation on the app overrides org-wide IP restrictions. Use only for integrations that genuinely run on dynamic IPs.
- Username-Password OAuth flow is supported but deprecation-flagged. New integrations should use Client Credentials or JWT Bearer instead.
Trust & references
Cross-checked against the following references.
- External Client Apps OverviewSalesforce Help
- Manage External Client AppsSalesforce Help
Straight from the source - Salesforce's reference material on External Client App Manager.
- External Client App OAuth SettingsSalesforce Help
- ExternalClientApp Metadata API ReferenceSalesforce Developer Docs
Hands-on resources to go deeper on External Client App Manager.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Governor Limit in the context of External Client App Manager?
Q2. What skill set is typically needed to work with External Client App Manager?
Q3. Where would a developer typically work with External Client App Manager?
Discussion
Loading discussion…