Why 'New Connected App' is Greyed Out in Salesforce (and How to Fix It)
You opened the App Manager, clicked the New Connected App, and nothing happened. The button is greyed out. Or it's gone entirely. If this started after February 2026, you're not hitting a bug or a permissions issue. Salesforce deliberately disabled Connected App creation for all orgs as part of the Spring '26 release.
Here's what changed, why it happened, and which path forward makes sense for your situation.
First, Is This the Spring '26 Change? (Quick Diagnosis)
Not every greyed-out button in Salesforce has the same cause. Before going further, confirm you're dealing with the Spring '26 enforcement:
| What you're seeing | Most likely cause | What to do |
|---|---|---|
| "New Connected App" button greyed out or missing entirely | Spring '26 enforcement, the most common scenario post-February 2026 | Keep reading |
| Button visible, save fails with a permissions error | Profile issue, System Administrator profile required for Connected App creation | Check your profile assignment |
| Button visible, save works, but OAuth flows fail | OAuth configuration error, a separate issue from the Spring '26 change | Jump to the ECA creation section below |
| Error: "Connected App must be installed in this org" | Uninstalled Connected App restriction from September 2025 | See the September 2025 Connected App restrictions guide |
If the button is greyed out or absent entirely, the Spring '26 enforcement is almost certainly the reason.
What's Actually Happening and Why Salesforce Did This
To understand why that button is gone, you need to know what happened in the twelve months leading up to Spring '26. I covered the full scope in my 2025 Salesforce breach security guide, here's the short version.
Three breaches, all in August 2025, all via Connected Apps:
Google: 2.55 million SMB Google Ads customer records extracted from their Salesforce CRM
Coca-Cola Europacific Partners: 23 million records stolen, accounts, cases, contacts, products
Salesloft-Drift supply chain: OAuth tokens stolen, then used to siphon Salesforce data from Palo Alto Networks, Cloudflare, Zscaler, Proofpoint, Tenable, and Qualys
The attack playbook came from ShinyHunters (Mandiant: UNC6040). Here's how it worked:
Attacker calls a Salesforce admin, posing as IT support
Walks them through App Manager to create a new Connected App
Admin enters an 8-digit "connection code", actually an authorization key
The "Data Loader" they're connecting is a rebranded app called "My Ticket Portal"
Once authorized: persistent privileged access to the org. MFA bypassed. Silent. Undetected.
The reason a million-dollar security stack couldn't stop a $45 phone call was structural. Connected Apps let any external app request authorization from any Salesforce user. No admin approval required. No IT ticket. No installation step. One phone call to the right person.
By September 12, 2025, the FBI issued a FLASH alert (FLASH-20250912-001) on threat actors specifically targeting Salesforce orgs this way. In October, an extortion group called Scattered Lapsus$ Hunters began publicly leaking breach data and extorting dozens of brands, including Salesforce itself.
Salesforce's first response came in September 2025: they restricted uninstalled Connected Apps and removed Device Flow. Useful patches, but patches. The underlying problem was the architecture. Spring '26 is the architectural answer.
Salesforce intentionally disabled the ability to create new Connected Apps. The rollout happened in stages:
Summer '25 (June 2025): Connected App creation disabled by default for new orgs
Winter '26 (October 2025): All newly provisioned orgs receive this restriction by default
Spring '26 (February 2026): Enforced across all existing orgs, including production instances
The critical clarification: this change affects creation only. Every Connected App you've already built continues to work. OAuth flows, API access, permission sets assigned to Connected Apps: none of that breaks. The restriction is purely on creating new ones.
Why the change? Connected Apps carried security baggage from an earlier era. The most significant issue was the username-password OAuth flow, which embeds credentials directly and makes it difficult to audit which application is accessing Salesforce versus which user. External Client Apps (ECAs) don't support that flow at all. The design forces modern OAuth patterns where the application identity is always explicit.
What Is an External Client App?
Think of an External Client App as a Connected App redesigned from the security review up, not just renamed. Salesforce introduced ECAs in Summer '25. Same core purpose: defining how an external system authenticates with Salesforce via OAuth. But the defaults are completely different from what you're used to.
With a Connected App, the model was open until an admin locked it down. With an ECA, it's locked until someone explicitly opens it. That shift matters because of exactly what ShinyHunters exploited. A Connected App could be used to authenticate against an org without being explicitly installed there, which Salesforce's own architects describe as a shadow connection risk. An ECA cannot authenticate against an org unless it exists there locally or is deployed via a managed package. The "My Ticket Portal" trick required the Connected App's global authorization model. That model doesn't exist in ECAs.
Second, ECAs separate developer settings from admin policies. A developer defines what the app can do (OAuth flows, scopes, callback URLs). An admin controls how and when access is granted in their specific org (token expiry, IP restrictions, permitted users). The two layers are independent, which matters especially for packaged apps distributed via AppExchange.
Which Fix Do You Need?
Your next step depends on your situation:
| Your situation | Best path |
|---|---|
| I need to create one Connected App right now for a legacy integration | Path 1: Re-enable Connected App creation |
| I'm building a new integration or starting from scratch | Path 2: Create an External Client App |
| I'm an ISV and this affects my AppExchange managed package | Path 3: ISV packaging guide |
Path 1: Re-Enable Connected App Creation (The Quick Fix)
If your org is on Summer '25 or Winter '26, you've got a switch to flip:
Setup > Apps > External Client Apps > Settings > Allow creation of connected apps
Enable that setting and the New Connected App button returns immediately. No support ticket, no waiting.
Important: this toggle does not exist in Spring '26 orgs. If you don't see External Client Apps > Settings or the toggle isn't present, you're past the point where this path works.
If the Toggle Is Gone (Spring '26 Orgs)
Contact Salesforce Support and request that Connected App creation be re-enabled. Include your org ID and two sentences on the technical limitation: what the integration is, why it needs a Connected App, and why ECA isn't yet viable for that specific case.
Salesforce will turn it back on, for now. The official documentation is clear that this option disappears in future releases. Use the support path to get unstuck today. Start the ECA migration before that window closes.
Path 2: Create an External Client App (The Right Way Forward)
If you're building anything new, skip the toggle entirely and go straight to ECA. The setup takes about ten minutes and the result is more secure from day one.
Step-by-Step: Creating Your First ECA
In Setup, search External Client App Manager in the Quick Find box and open it
Click New External Client App
Enter a name; the API name fills automatically. Add a contact email.
Set Distribution State to Local for org-specific integrations (if you're building a managed package, see Path 3)
Check Enable OAuth Settings
Enter your Callback URL, the endpoint Salesforce redirects to after authentication
Select your OAuth Scopes (see the table below)
Enable Token Exchange Flow, check Require secret for Token Exchange Flow, and check Require secret for Web Server Flow
Click Create
Open the newly created app, go to the Settings tab, expand OAuth Settings, click Consumer Key and Secret, and save both values securely
Which OAuth Scopes Do You Need?
| Scope | Use when |
|---|---|
| api | Standard Salesforce API access, required for most integrations |
| refresh_token, offline_access | Long-running integrations that operate without user interaction |
| web | Browser-based flows where users authenticate through a web interface |
| full | Full API access, use sparingly; justify the scope to your security team before enabling |
A Note on Security Settings
Token Exchange Flow enables secure server-to-server token exchange, useful when a third-party identity provider issues tokens that need to be swapped for Salesforce access tokens.
PKCE (Proof Key for Code Exchange) should be enabled for public clients: mobile apps, single-page apps, or any scenario where the client secret can't be stored securely on the device.
Refresh Token Rotation invalidates the used refresh token and issues a new one on each refresh. More secure, but it adds overhead. If your integration doesn't handle a changed token gracefully, you'll get intermittent auth failures, and that's fun to debug. Test it in a sandbox before enabling in production.
Take a look through all the ECA settings. What's missing? The username-password flow. It hasn't been hidden or renamed, it's just gone.
Got an integration running on embedded credentials? That's the refactor you've been putting off. Automations talking server-to-server go on Client Credentials Flow. Anything user-interactive goes to Authorization Code Flow with PKCE. These aren't quick swaps. But they're the right ones, and not just because Salesforce is making you.
Path 3: The ISV View: What AppExchange Partners Need to Do
So, how does this change things for ISVs? Connected Apps were always a bit of a workaround inside a 2GP package, technically possible, but with enough friction that the subscriber org experience was never quite right. Admins would often have to manually install the app. Package deployments would break. Every AppExchange security review surfaced the usual concerns. ECAs are the first time Salesforce built the packaging story for how ISVs actually distribute through AppExchange.
How ECAs Fix the 2GP Packaging Problem
Connected Apps in Second-Generation Packages (2GP) required workarounds to deploy cleanly across subscriber orgs. ECAs are built for this use case. Set Distribution State to Packaged and the ECA becomes part of your managed package metadata, deploying to subscriber orgs like any other component.
The developer-admin policy separation matters here more than anywhere else. A subscriber org admin can adjust token expiry or IP restrictions in the policies layer without your developer configuration being affected, and without requiring a new package version from you. For ISVs managing large installed bases, that's a meaningful operational change.
Your Migration Checklist
Inventory all Connected Apps across your org and managed packages
Identify which are local (created in-org, not packaged) vs packaged (shipped inside a managed package)
For local Connected Apps: in App Manager, find the app and select Migrate to External Client App, this automated path preserves your existing Consumer Key and Secret, so external systems don't need credential updates
For packaged Connected Apps: create a new ECA with Distribution State: Packaged, then release a new package version
Test in a sandbox before promoting to production
After automated migration, verify the app appears in Notification Delivery Settings and Briefcase assignments, migrated apps occasionally require manual reassignment in these areas
Update your packaging metadata to reference the ExternalClientApplication metadata type
Communicate the timeline to your installed base if you're releasing a new package version
Salesforce-managed apps (Data Loader, Salesforce CLI, Salesforce Mobile App) are Salesforce's responsibility. Don't include them in your migration inventory.
Why This Change Is Actually Good (Even If the Timing Isn't)
Here's the thing: most Salesforce architects would have recommended moving away from Connected Apps even if Salesforce hadn't forced it.
The username-password OAuth flow was always a security anti-pattern. Credentials embedded in integration configs, no reliable way to tell whether a human or a system is driving access, incident response made harder because the trail was never clear, these were real problems, not theoretical ones. And to make things worse, the "default open" discovery model let external tools authenticate against an org before an admin even knew the tool existed. That's precisely the kind of quiet vulnerability that keeps showing up in post-incident reviews.
ECAs enforce a cleaner model. Every inbound integration has an explicit client identity. Scopes are tied to that identity. Admin policies govern access without touching developer configuration. For ISVs, the 2GP packaging support eliminates months of workarounds that previously surfaced in every AppExchange security review.
Salesforce's timeline was aggressive, especially for ISVs mid-release-cycle. But the destination is defensible. The September 2025 uninstalled app restrictions were the first signal this was coming. Spring '26 is the continuation of the same architectural direction.
The Bottom Line
The greyed-out button is deliberate. Salesforce disabled Connected App creation across all orgs in Spring '26 as part of a planned migration to External Client Apps.
Existing Connected Apps continue to work. Only new creation is blocked. Your path forward:
Toggle still available (Summer '25 / Winter '26 orgs): Setup > External Client Apps > Settings > re-enable the toggle
Toggle gone (Spring '26 orgs): Support ticket for a temporary exception, ECA migration running in parallel
Building something new: Create an ECA directly, ten steps, ten minutes, and the architecture is genuinely better
ISV with packaged Connected Apps: Automated migration for local apps (credentials preserved), new package version for packaged apps
The Spring '26 enforcement caught a lot of teams off guard. The migration, once you've done it, is cleaner than it looks from the outside.
Have you started migrating your Connected Apps? Which path are you on, the quick toggle fix, a full ECA build, or an ISV package migration? Drop a comment.
Navigating this migration for your org or your AppExchange package? Concret.io helps Salesforce teams migrate integrations and maintain ISV certifications. Talk to our team.
Let’s Talk
Drop us a note, we’re happy to take the conversation forward 👇🏻
