You can't create a new connected app in Salesforce on your own anymore. Since Spring '26, creation is off in every org, in Setup and through the Metadata API, and only Salesforce Customer Support can switch it back on. What you build instead is an External Client App (ECA), which holds the same client ID, client secret, callback URLs and OAuth scopes.
For a SaaS company the real question is bigger than one set of keys. A customer-facing integration needs an app that installs cleanly into every customer's org and passes their admin's policies. If it ships as a packaged app, it also has to meet Salesforce's partner security rules. Appnigma's free External Client App tool creates the app for you and returns the keys and a managed package link. The slow part usually comes after that. Our integration infrastructure handles the registration and authorization work that happens "before the first launch" for each customer org.
Updated October 2026. Checked against the Spring '26 release note, Salesforce knowledge article 005228017, the ECA metadata reference and the partner OAuth security guide. This update corrects the product name to External Client App and fixes a broken tool link. It also corrects how the secret works in Salesforce and removes an unsourced release date. It adds packaging, per-customer policies, flow choice and the partner security controls.
Can you still create a connected app in Salesforce?
Only by asking Salesforce Support, and that route has an end date. The Spring '26 release note says "the ability to create connected apps is disabled" and that the "Allow creation of connected apps preference in External Client App Settings is also removed." So no profile, permission set or Setup toggle brings the New Connected App button back.
Salesforce's knowledge article 005228017 fills in the rest. Creation "via APIs (including the Metadata API) is blocked in the same way as the UI," with "the exception of package installation." Support can still enable creation for an org today, but the article adds that "in future releases, Salesforce Support won't be able to enable the creation of new connected apps."
| Situation | What Salesforce allows | Source |
|---|---|---|
| Before Spring '26 | New orgs had creation off, and an admin could turn on "Allow creation of connected apps" | KA 005228017 |
| Since Spring '26 | Creation blocked in Setup and the Metadata API, preference removed, Support request only | Spring '26 release note |
| Future releases | Support will no longer be able to enable creation | KA 005228017 |
| Existing connected apps | Keep working, can be edited, installed and deleted | KA 005228017 |
| Connected apps inside managed packages | Still install into new orgs | Spring '26 release note |
Nothing you already run breaks. The release note says existing connected apps "will continue to function normally," and the knowledge article says they are "not yet at End of Support." It also says an End of Support date will be announced. If you ship a connected app inside a managed package, the article puts migration on you: "it is the ISV's (the vendor's) responsibility to provide a migrated ECA version."
This also ends a common onboarding pattern. Many integrations used to ask each customer's admin to create a connected app and paste the keys into the product. Customers are under the same block, so that step now fails in every new customer org. The fix is to ship your own app, packaged, for customers to install.
Older guides, and several Salesforce developer pages, still tell you to turn on "Allow creation of connected apps." That step describes the setup before Spring '26.
Local or packaged, which External Client App a SaaS integration needs
An ECA does the job a connected app did, but Salesforce designed it around packaging. Salesforce's comparison of connected apps and ECAs calls ECAs "the new generation of connected apps." It says they "maintain a clean separation between proprietary developer settings and the customizable, admin-defined policies." The choice that matters for a SaaS team is the ECA's distribution state.
| Local ECA | Packaged ECA | |
|---|---|---|
| Lives in | The org where you create it | A managed package your customers install |
| Fits | Your own backend talking to your own org | A product that connects to many customer orgs |
| Who sets OAuth policies | You | Each customer's admin, starting from your packaged defaults |
| Copied into sandboxes | No | Yes |
| Packaging | Not distributed | 2GP managed packages, and 1GP is also supported |
Salesforce's 2GP packaging guide says ECAs "can be packaged in first-generation managed packages or second-generation managed packages." The knowledge article adds a detail customers notice in testing. "Only packaged external client apps are copied to the sandbox," so a customer who refreshes a sandbox gets your app there only if it was packaged.
The split between settings and policies changes how you ship. Your consumer key, secret and callback URLs sit in global OAuth settings, which Salesforce says "can't be packaged and must not be added to source control." What travels to the customer are the configurable policies. They include who may use the app, either AllSelfAuthorized or AdminApprovedPreAuthorized. If a customer's admin picks admin approval and forgets to assign a permission set, every user in that org sees an access error. Your code did nothing wrong. Put that step in your install guide.
Getting a client ID and secret without opening Setup
Appnigma's External Client App tool creates the ECA for you. You don't need a Dev Hub, a namespace, the Salesforce CLI or a partner application. You sign in at platform.appnigma.ai with an emailed code, name the app, add redirect URLs and pick a scope preset. That part takes a couple of minutes. Provisioning then runs in the background, and the tool's own progress screen says it takes about 20 minutes.
The client ID is Salesforce's consumer key and goes in the client_id parameter of your authorize URL. The secret is the client_secret your backend sends when it exchanges the code for tokens. The tool shows the secret once, so have your secret manager open before you reveal it. Register every environment's redirect URL up front, such as localhost, staging and production. Redirect URLs and scopes stay editable, and a scope change builds a new package version, which takes a few minutes.
Plan for the customer's sandbox too, since many enterprise customers test there before production. Sandbox users authorize at a different host. Salesforce's hosted MCP Postman guide lists https://test.salesforce.com/services/oauth2/authorize for sandbox and scratch orgs, so your connect screen needs a sandbox option. Your app is only present in that sandbox if it was installed as a package.
The package link is the part that reaches customers. It is a standard Salesforce install URL, and the tool shows it once the package is ready for production orgs, which can be after your keys work. One client ID and secret then serve every org that installs it, because Salesforce keeps the credentials in the source org instead of the package. Each customer's admin still installs the package and sets the app's policies in External Client App Manager. That covers permitted users, profiles or permission sets, IP relaxation and the refresh token policy. If you only connect your own org, you can ignore the link.
The link is for installs, not for an AppExchange listing. Salesforce connects a package to the Partner Console through "the login credentials for the Dev Hub or packaging org that contains the package," and the tool never uses yours. A team that wants its own listing and security review needs the package in its own namespace. Our marketplace apps service builds that package and supports the review.
Which OAuth flow and scopes should a multi-org backend use?
Most customer-facing integrations should use the web server flow, also called authorization code. Each customer's user approves your app once. Your backend stores that org's refresh token and instance_url, then calls the API for that customer. PKCE is on by default for ECAs. The global OAuth settings reference says isPkceRequired is "true (default)."
The client credentials flow suits a different case. It runs as a single execution user that an admin sets inside one org, and that user "must have the API Only permission." That works for one org you control. Across many customer orgs, every admin would have to create and maintain that user. The username-password flow is off the table for ECAs. Salesforce says it "won't be made available for external client apps."
The tool's presets map to common jobs.
| Preset | Scopes | Fits |
|---|---|---|
| Data only (3) | api, refresh_token, web | Backend syncs and scheduled jobs that never need to know who the user is |
| Data plus sign-in (7) | Adds openid, profile, email, offline_access | Products where people sign in with their Salesforce account |
| Full access (13) | Adds address, phone, content, custom_permissions, wave_api, eclair_api | Prototyping, then narrow it before customers see it |
The Data only preset is the same three scopes that Salesforce's scope reference calls sufficient for most apps. It also says refresh_token "is synonymous with requesting offline_access." One trap sits outside the presets. Salesforce's full scope "doesn't return a refresh token," so a backend that requests full without refresh_token loses access when the session ends. Customer security teams review the scope list before they approve an install, and a short one gets through faster.
Creating the External Client App yourself in Salesforce
Build it by hand when you want the ECA in your own Dev Hub and your own managed package from day one. In External Client App Manager you create the app, fill in the OAuth settings and set the distribution state to Packaged. Our External Client App guide walks through each screen, and the Developer Edition access guide covers getting an org.
Three details catch teams used to connected apps. The keys sit behind the Consumer Key and Secret button, and Salesforce's Analytics SDK setup guide says "you can view the consumer key and secret or generate a new consumer secret." A new secret invalidates the old one at once, so rotate during a deploy window, not while customers are syncing. Salesforce's hosted MCP guide says a new ECA "can take up to 30 minutes to become available and operational." The same guide says you can't create ECAs in scratch orgs through Setup, so CI pipelines install the app as a package instead.
What changes once the app runs in customer orgs
A partner app that reaches its third customer production org has to meet extra OAuth rules. Its partner security guide covers any connected app or ECA "in use by more than two customer production orgs." Four controls were due by May 11, 2026. They are PKCE, refresh token rotation, a 30-day idle refresh token timeout and a refresh token IP allowlist of up to 256 addresses. After you attest to them, the guide says, "the security controls are locked and can't be disabled."
The idle timeout is the one that reaches your support queue. Salesforce "invalidates the idle refresh token after 30 days," so a customer whose integration stays idle for a month loses their connection. That might be a seasonal customer, or a trial org that went quiet. Build a reconnect prompt into your product before that customer finds the problem for you. Rotation also means each refresh returns a new refresh token. Store it every time, per org, or the next refresh fails.
Listing a managed package on AppExchange adds Salesforce's security review. Our marketplace apps page notes that "Salesforce AppExchange requires security review for the app," and the service covers the managed package and "Salesforce security review preparation and responses." Our post on the connected app security deadline goes through the controls one by one.
Mistakes that break the OAuth handshake after install
- Registering
https://app.example.com/callbackand sendinghttps://app.example.com/callback/. Salesforce says the callback URL must match exactly, "including whether it has a trailing slash." - Mixing purposes on one app, such as a web callback and a mobile custom scheme. The partner security guide says to avoid "multiple callback URLs that have a mixed purpose."
- Testing a brand new ECA right away and debugging an error that clears itself within 30 minutes.
- Keeping one refresh token for the whole product instead of one per customer org.
- Shipping the Full access preset because it worked in your own org.
- Testing only in a clean Developer Edition org, when customers have restricted profiles, permission sets and required custom fields.
Frequently Asked Questions
Why is the New Connected App button missing in Salesforce?
Spring '26 disabled connected app creation in every org and removed the "Allow creation of connected apps" setting. Profiles and permission sets can't restore it. Only Salesforce Customer Support can, so create an External Client App instead.
Do I need a separate External Client App for each customer?
No. One packaged ECA installs into every customer org, and each org's authorization gives your backend its own refresh token and instance URL. Our connected app vs external client app comparison covers how this differs from connected apps.
Do existing connected apps stop working?
No. Existing connected apps keep working and still install through managed packages. Salesforce says an End of Support date will be announced, and packaged apps then need an ECA version from the vendor.
Can I see my ECA consumer secret again after creating it?
In Salesforce, yes. The Consumer Key and Secret button under OAuth Settings shows it again, and generating a new secret invalidates the old one immediately. Appnigma's tool shows the secret once, so store it when you reveal it.
Can Appnigma create a Salesforce External Client App for my integration?
Yes. The free External Client App tool asks for a name, redirect URLs and scopes, then provisions the app in about 20 minutes. It returns a client ID, a secret and a managed package link, with no credit card and no partner application.
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- What Is an External Client App (ECA) in Salesforce, and How to Create One
- Connected App vs External Client App in Salesforce
- The Salesforce Connected App Security Deadline
- How to Get an OAuth Access Token in Salesforce
- Salesforce OAuth Errors and Troubleshooting
- How to Create an External Client App for Nango
Sources
- Salesforce Help, Spring '26 release note, Creation of New Connected Apps Is Disabled by Default
- Salesforce Help, Knowledge article 005228017, New connected apps can no longer be created in Spring '26
- Salesforce Help, Comparison of Connected Apps and External Client App Features
- Salesforce Developers, ExtlClntAppGlobalOauthSettings metadata type
- Salesforce Developers, ExtlClntAppOauthConfigurablePolicies metadata type
- Salesforce Developers, Secure Your Connected Apps and External Client Apps
- Salesforce Developers, Package Connected Apps in Second-Generation Managed Packages
- Salesforce Developers, OAuth Scope Parameter Values
- Salesforce Developers, Hosted MCP Servers, Create an External Client App
- Salesforce Developers, Hosted MCP Servers, Connect with Postman
- Salesforce Developers, Analytics SDK, Set Up Authentication with External Client Apps
- Salesforce Developers, Data 360 Google Analytics connector credentials
- Salesforce Help, Package an External Client App
- Salesforce Developers, Connect Your Solution to the Partner Console
- Salesforce Developers, Sign Up for a Developer Edition Org
- Appnigma, Salesforce External Client App tool
