• Gravatar
• LinkedIn

There’s a quiet revolution happening in Salesforce land. Something we’ve relied on for years—Connected Apps—is slowly making its way to retirement. And taking its place is something more modern, secure, and scalable: External Client Apps.

If you’ve ever integrated Salesforce with external systems, you know the drill. For ages, Connected Apps were our gateway: define an app, set the OAuth policies, and let external systems talk to Salesforce. Simple, but not always scalable.

So why is Salesforce moving away from Connected Apps? And why should you care?

Let’s walk through the story.

---

The Old World: Connected Apps

Connected Apps were like custom gates you had to build in every org you wanted to connect. Want to connect three sandboxes and one production? You needed to replicate your Connected App in all of them.

• No packaging.
• No clean promotion through environments.
• No true “multi-org” support.

It worked, but it was clunky. Admins and developers had to repeat the same process across orgs, and managing client credentials was painful.

---

The Shift: External Client Apps

Enter External Client Apps. Think of them as the modernized, packageable evolution of Connected Apps.

• They are first-class citizens in Salesforce packaging.
• They can be created once and reused across multiple orgs.
• They offer stronger security and compliance alignment.
• They fit perfectly into the Second-Generation Packaging (2GP) ecosystem.

Salesforce wants to standardize authentication the same way they standardized metadata with 2GP. External Client Apps give us a structured, consistent way to manage OAuth across multiple environments and customers.

---

A Real Example: Packaging an External Client App

To really see how this works, let’s walk through an example where we package an External Client App. This is the part where old Connected Apps fall short, and External Client Apps shine.

Step 1: Setup Your Dev Hub

First, create a forever Salesforce Developer Org and enable Dev Hub. This is where all packaging magic begins.

Step 2: Namespace Registration

Next, create a second Developer Org just for namespace registration. This namespace is the unique identity of your package.

Link it back to your Dev Hub through the Namespace Registry app.

Step 3: Create an External Client App

In your Dev Hub, create a packaged External Client App. Unlike Connected Apps, this is not tied to just one org—it can be packaged and installed elsewhere.

Step 4: Authorize in VS Code

Using Salesforce CLI, authorize your Dev Hub:

sfdx auth:web:login --setdefaultdevhubusername --alias DevHub

Retrieve your External Client App and its OAuth settings.

Step 5: Package It

Now, create a managed package:

sf package create --name "MyExternalClientAppPkg" --path force-app --package-type Managed

Add your namespace to sfdx-project.json, then build a package version:

sf package version create --package "MyExternalClientAppPkg" --code-coverage --installation-key-bypass

Promote it when you’re ready for release.

---

The Big Payoff: Multi-Org Compatibility

Here’s where External Client Apps truly outshine Connected Apps. Once packaged, you can install the app into any org—sandbox, production, customer tenant—and it just works. No need to manage client credentials for each org and their client apps. It works for the one single client app’s client credentials.

No need to manually recreate Connected Apps everywhere.
No headaches maintaining client IDs across orgs.
No inconsistent OAuth settings.

Instead, you get a repeatable, secure, scalable authentication model that Salesforce is betting its future on.

---

Why Salesforce Is Making This Change

Salesforce is pushing External Client Apps because:

• Packaging → Deployment automation (DevOps-friendly).
• Security → Stronger governance and control.
• Multi-Org Scalability → One app, many orgs.
• Future-Proofing → Connected Apps will eventually be deprecated.

This shift mirrors Salesforce’s larger strategy: moving from legacy, one-off setups toward a modular, packaged, and governed model.

---

Final Thoughts

Think of this as Salesforce finally giving us a “Connected App 2.0”. By embracing External Client Apps, we’re not just modernizing how we authenticate—we’re preparing for a world where integration has to be secure, repeatable, and cloud-native.

So, if you’ve been living in the Connected App world, it’s time to start experimenting with External Client Apps. Package one, deploy it, and feel the difference.

Connected Apps had a good run. But the future belongs to External Client Apps.