#External Application6 personnes en discutent

Hey Marc, 

Two documented causes match your symptoms exactly: 

1. Missing profile permission (most likely first check) 

Your profile needs the specific permission "View all External Client Apps, views their settings, and edit policies." System Administrator profile usually has broad access, but this is a distinct, separate permission from general admin rights, if it's not explicitly enabled on your profile (or if your org customized the System Admin profile), you'll get exactly this "Insufficient Privileges" page after verification. Check Setup > Profiles > your profile > System Permissions, confirm this specific one is checked. 

2. Permission Set License not synced to sandbox (matches your multi-env setup) 

There's a documented issue where the External Client App framework requires a specific Permission Set License, and if your Production/Hub org has it but your Sandbox (dev/qa) wasn't refreshed after that license was added, the sandbox literally doesn't have the underlying license, so the UI permission stays inactive even for System Admins. Fix: Setup > Company Information > click "Match Production Licenses" in the sandbox, then check if the External Client App Permission Set License now appears under Permission Set Licenses. This would explain why qa worked (possibly synced more recently) while dev/hub didn't. 

On your permission set issue specifically, permission sets can't grant this, it's a Permission Set License requirement, not a regular permission, that's likely why assigning it to your user failed or didn't help, licenses need to exist at the org level first before any permission set/profile setting can actually take effect. 

Reference:

Hey Ramandra, 

Himanshu's answer is accurate and matches what's actually being reported. Real-world evidence backs this up: even after explicitly turning on "Allow OAuth Username-Password Flows," users are still getting a "Username-Password Flow Disabled" error, confirming the toggle alone doesn't guarantee the flow will work, Salesforce's platform-level retirement enforcement can override it regardless of your org setting. 

So to your three original questions: 

- The setting existing and being toggleable doesn't mean the flow will actually function, this is confirmed behavior people are hitting even now 

- Whether Support can override this for validation purposes is genuinely a case-by-case Support/AE conversation, not something the community can confirm 

- Not edition-specific, it's the platform-wide retirement, not a licensing tier restriction 

Practical suggestion: since you're already building the Client Credentials integration, validate it independently rather than trying to get the legacy flow re-enabled for a side-by-side. Compare against logs/behavior from your old integration instead of live-running both simultaneously, that avoids being blocked by something Salesforce is actively phasing out. 

Reference:

@damian humphrey Yes - I've used the Requirements object to store budget and programmatic reporting information in OFM. And then in case we used FormAssembly (a 3rd party app) as the form tool that the grantees used to complete applications and reports. For another case, we used screen flows in a Salesforce Community/Experience for the forms the grantees submitted. It really came down to the experience the foundation wanted the grantees to have.    We have also built out customized Review process and portal where we created a mass review assignment and side by side review and feedback screen. As well as a custom Due Diligence/Compliance process that can be managed directly from the Funding Request page.