OAUTH_APPROVAL_ERROR_GENERIC: The 2025 Salesforce Change That Breaks Integration Logins
Salesforce quietly started blocking OAuth for uninstalled connected apps. Why your integration user can't authorize, and the four other traps waiting behind it.
You’re connecting a third-party tool to Salesforce — a donation platform, a form builder, a sync service. You click Connect, log in as your integration user, and instead of the OAuth consent screen you get:
OAUTH_APPROVAL_ERROR_GENERIC
No detail. Nothing useful in the debug logs. The same connection worked fine for another org last year, and every tutorial for your tool shows the consent screen appearing right where you’re stuck. I burned a real afternoon on this one before finding the cause, so here it is for the next person searching that error string.
What changed
In August 2025, Salesforce announced it would block end users from authorizing connected apps that aren’t installed in the org, and the enforcement landed with the September 2025 updates. Before that, any user could OAuth into a third-party app and Salesforce would create the connected app record on first use. Now, if the app isn’t already installed, the authorization is refused — with the world’s least helpful error message.
Alongside the block, Salesforce added a new system permission: “Approve Uninstalled Connected Apps.” Users who have it can authorize apps the old way. Users who don’t — which is everyone, by default, including your carefully-locked-down integration user — get the generic error.
The fix (pick one)
- Install the connected app. Setup → Connected Apps OAuth Usage → find your app → Install. This is the cleanest answer for a production integration: the app becomes a managed, visible part of your org.
- Grant the permission. Add “Approve Uninstalled Connected Apps” (System Permissions) to a permission set and assign it to the user doing the authorization. Appropriate for admins who connect lots of tools; overkill as a permanent grant on an integration user.
- Sandbox special case: if this appears only in a sandbox, run Match Production Licenses (Setup → Company Information) — sandbox license definitions drift and can drop the permission’s availability entirely.
The four traps behind this one
I hit this error while standing up a dedicated integration user for a nonprofit’s donation sync, and it was only the first of five problems in that gauntlet. If you’re doing the same build, save yourself the other four afternoons:
The free Integration license drops your permission sets. Salesforce gives most orgs five free Salesforce Integration licenses — API-only, perfect for this. But changing a user’s license silently unassigns their permission sets. If you set everything up on a full license and then flip to the free one to release the seat, reassign the permission sets afterward, or the integration starts failing auth in a completely different way.
Profile changes reset the default record type. Moving the user to a new profile can leave it with a default record type you didn’t intend — and an API client that doesn’t specify a record type gets the profile’s default. Every record the integration creates lands with the wrong type, quietly.
Universally-required fields block the API. If a custom field is marked required on the field definition itself, every API insert that doesn’t supply it fails — even though human users never see a problem, because the page layout always collects it. If the integration can’t send the field, make it required on the page layout instead; layouts don’t apply to the API.
The vendor’s error message is worse than Salesforce’s. When the sync
fails, don’t debug through the third-party tool’s logs. Replicate the exact
insert with the sf CLI, authenticated as the integration user. The raw API
error tells you the actual field, rule, or permission at fault in one shot.
The pattern worth keeping
Dedicated integration user, Minimum Access profile, one permission set that grants exactly the objects and fields the tool needs, free Integration license once it’s proven. It’s more setup than reusing an admin’s credentials — and it’s the reason your sync survives the day that admin changes their password or leaves.
Further reading
- CData — Action required: Salesforce connected app usage changes, September 2025
- Nango — Fixing OAUTH_APPROVAL_ERROR_GENERIC
- ForceTrails — Salesforce OAuth breaking with “app must be installed into org”
I’m Chris Moore — an independent consultant in Henderson, NV. I do this kind of integration rescue for small teams and nonprofits, including pro-bono work through Catchafire and Taproot. Stuck on a sync that used to work? Get in touch.