Salesforce integrations are evolving fast. If you’re still relying only on Connected Apps, you might already be a step behind. Salesforce introduced External Client Apps to provide a more secure, scalable, and future-ready way to integrate external systems.

Think of it like upgrading from a basic lock to a smart security system—same goal, much better control.

An External Client App is a Salesforce app type designed specifically for external applications—such as mobile apps, web apps, backend services, or SaaS platforms—that need secure access to Salesforce APIs using OAuth 2.0.

Unlike Connected Apps, External Client Apps are not tied to a specific user context by default, making them ideal for modern machine-to-machine and multi-tenant integrations.

A key concept that uniquely defines an External Client App is its Distribution State. The distribution state determines where and how the app can be used—whether it is restricted to a single Salesforce org or distributed across multiple orgs, customers, or environments. This capability fundamentally differentiates External Client Apps from legacy Connected Apps.

Salesforce is actively steering developers toward External Client Apps because they:

• Offer better security isolation

• Support modern OAuth flows

• Are optimized for machine-to-machine communication

• Align with Salesforce’s long-term API and integration strategy

If you’re building anything external today, this is the direction Salesforce expects you to follow.

Before creating one, it’s important to understand how External Client Apps differ from traditional Connected Apps.

Both use OAuth. Both allow API access. But they are not interchangeable.

The Distribution State is one of the most important—and least documented—features of External Client Apps.

It defines whether an app is:

• Local – Used only within the Salesforce org where it is created

• Distributable – Intended to be shared across multiple Salesforce orgs, customers, or tenants

This setting directly impacts how the app authenticates, scales, and complies with Salesforce’s security model. Unlike Connected Apps, which are inherently org-bound, External Client Apps are designed with distribution and multi-org usage in mind from the start.

Use External Client Apps for:

• Backend services

• SaaS integrations

• Mobile or web applications

• Multi-org or customer-facing integrations

Use Connected Apps only for:

• Legacy systems

• Salesforce UI extensions

Preparation saves hours of debugging later.

Make sure:

• You have System Administrator access

• Your org is Enterprise, Unlimited, or Developer Edition

• API access is enabled

External Client Apps rely fully on OAuth 2.0, so understanding tokens is essential.

• Client Credentials Flow

• Authorization Code Flow

• JWT Bearer Flow

Each flow serves a different use case—choose based on your architecture.

Let’s walk through the setup.

• Log in to Salesforce

• Click Setup (top-right corner)

In Setup:

• Search for External Client Apps

• Click External Client Apps

• Select New External Client App

This is where your app takes shape.

• App Name: Human-readable (e.g., My Integration App)

• API Name: Auto-generated

• Contact Email: Used for security and system notifications

During creation, you must define the Distribution State of the External Client App.

• Local apps are restricted to the current Salesforce org

• Distributable apps are designed for use across multiple orgs or customer environments

This decision directly affects scalability and reuse. Choosing the wrong distribution state can limit how your app can be deployed later.

Enable OAuth and configure secure access.

• Callback URL: Required for Authorization Code flow

• Scopes:

  • api

  • refresh_token

  • openid (optional)

Grant only what your app actually needs.

• Click Save

• Activate the app

• Copy the Client ID and Client Secret

Store these securely. Treat them like passwords.

Security is not optional.

• Create a permission set

• Assign required API permissions

• Link it to the External Client App

Define:

• Access token lifespan

• Refresh token behavior

• Rotate secrets regularly

• Revoke unused tokens

• Monitor token usage

Always test before production.

Use tools such as:

• Postman

• Curl

• OAuth playgrounds

Test basic operations:

• Query Accounts

• Fetch User or Org data

• Invalid scope → Review OAuth settings

• Unauthorized → Verify permission sets

• Token expired → Refresh the token

This is where External Client Apps truly shine.

Ideal for:

• iOS apps

• Android apps

• React Native or Flutter apps

Perfect for:

• ETL pipelines

• Middleware platforms

• Background jobs

These integrations typically rely on Distributable External Client Apps to support multi-org deployments.

Excellent for:

• SaaS platforms

• Analytics tools

• Automation systems

SaaS providers depend on Distributable distribution states to connect securely with multiple Salesforce customer orgs.

Small habits make a big difference.

• Apply least-privilege OAuth scopes

• Rotate secrets periodically

• Enable IP restrictions when required

• Cache access tokens

• Minimize API calls

• Use Bulk API for large data operations

• Track authentication failures

• Monitor token usage

• Set alerts for unusual activity

Salesforce recommends External Client Apps for all new external integrations. Avoid building on deprecated patterns.

Granting excessive access increases security risk without benefits.

Treating External Client Apps like Connected Apps and overlooking the Distribution State is a common mistake. Choosing the wrong state can limit scalability or require recreating the app later. Always align the distribution state with your deployment model from day one.

They work seamlessly together.

Best suited for:

• Real-time operations

• Lightweight requests

Use when:

• Handling large data volumes

• Subscribing to platform events

• Respect daily API limits

• Implement proper rate limiting and retries

Even well-configured apps can encounter issues.

• Verify client credentials

• Confirm OAuth flow selection

• Check assigned permission sets

• Validate OAuth scopes

Salesforce has made its direction clear.

External Client Apps are:

• More modular

• More secure

• More scalable

• Improved tooling

• Enhanced OAuth controls

• Deeper API governance

Creating an External Client App in Salesforce is more than a setup task—it’s a strategic architectural decision. It future-proofs your integrations, improves security, and aligns your systems with Salesforce’s roadmap.

With features like Distribution State, External Client Apps enable scalable, multi-org integrations that Connected Apps were never designed to handle. If you’re building anything external today, this approach is no longer optional—it’s essential.

1. Is External Client App replacing Connected App in Salesforce?
Not entirely, but Salesforce strongly recommends External Client Apps for all new external integrations.

2. Which OAuth flow is best for backend integrations?
Client Credentials or JWT Bearer flow works best for server-to-server use cases.

3. Can External Client Apps access all Salesforce APIs?
Yes, provided the correct scopes and permissions are configured.

4. Do External Client Apps require a Salesforce user?
No. They can operate without a direct user context.

5. Are External Client Apps more secure than Connected Apps?
Yes. They offer improved isolation, token control, and modern OAuth handling.

6. What is the Distribution State in an External Client App?
The Distribution State defines whether an External Client App is restricted to a single Salesforce org (Local) or can be distributed across multiple orgs and customers (Distributable). It is a foundational difference from Connected Apps and directly affects scalability and usage.