#External Service2 utenti parlano di questo argomento

Hi @Neha Chandra

Good news, this is solvable, and it's almost certainly a schema issue, not a fundamental limitation. 

Root cause: With Client Credentials Flow, the Named Credential/External Credential is supposed to fetch and inject the token automatically you should never need to supply it manually. The fact that Flow is prompting for an "Authorization" input almost always means the OpenAPI schema you registered for the External Service explicitly defines Authorization as a header parameter (common when a schema is auto generated from Postman/Swagger export, which bakes in an Authorization header as part of the spec). External Services then dutifully surfaces that as a required input on the Flow action even though the Named Credential is already handling auth underneath it. 

Fix: 

1. Open the OpenAPI schema registered on your External Service (Setup → External Services → your service → Actions/Schema).
2. Find the Authorization header parameter definition on the relevant operation(s) remove it entirely or set it to required: false and don't map it in Flow.
3. Re-save/re validate the External Service so it regenerates the invocable action without that input.
4. Separately, confirm on the External Credential itself: the Principal has "Generate Authorization Header" (or equivalent auto-token-injection setting) enabled, and the running user has access via External Credential Principal Access (Setup → your External Credential → Edit Principal Access, or Permission Set External Credential Principal Mappings pre-Winter '25 style naming).

Once the schema no longer declares Authorization as a parameter the Flow action should drop that input field and the Named Credential will inject the token transparently on every callout same as it would in Apex. 

If after removing it from the schema Flow still prompts, double check you're invoking the action through

pointed at the Named Credential with a manually-built header) those are two different Flow elements and it's easy to end up on the wrong one when troubleshooting. 

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

On the Named Credentials page, you need to click New Legacy instead of New.

Hi @Pratik Patil,

These errors can be hard to debug. The best way to get a quick turnaround on this.

First Method: Set-up the debug log for the user who is getting this error.

Try to reproduce the error and analyze the debug log to check the root cause.

Second Method: If the debug log won’t give you much information about this error then you have the only way to resolve it in less time which is to log a case with Salesforce support.

Please share the below information on your case to get a quick response on it.

• Login access to your affected org(in which the issue is occurring).
• Complete the steps to reproduce the error again.
• Complete the error message with the error ID.
• Attach the snapshot of the error on the case
• Provide your availability hours.
• Date and time when the error occurred the first time.

Support will track the stack trace at your org instance try to find out the root cause of the error and suggest the appropriate solution for the error.

The above information will help them to filter out the server logs.

If still facing errors kindly share the flow error screenshot along with the error screenshot.

I hope this helps!

Thanks

Saurabh

I saw that, but the only solution suggest was something about special characters. It doesn't explain why it was working a few days ago.

But, then I noticed a 'Z' a the end of the date field. No idea why that suddenly started being sent by the 3rd party system.

So, in summary. it was data being sent in the incorrect format

Dug through this with one of my Salesforce SMEs.  Here are the fixes:

• Change Named Credential to password auth
• Remove Auth header from External Service
• Use the Apex Defined variable for the URL encoded parameters and pass that to the 'generated' field on the Action.  This is what I initially overlooked.
• Do not specify any responses in the API spec in Mulesoft Exchange

For whatever reason, defining responses in the API spec caused Salesforce to fail parsing the response every time.