This just started randomly the other day. I am self-hosted.
When executing any workflow, any step that uses a connection will show a red triangle with a message like “Credentials with name n8n-SharePoint do not exist for Microsoft SharePoint OAuth2 API. You can create credentials with the exact name and then they get auto-selected on refresh..”
But, those steps and the workflow as a whole run just fine. I hadn’t changed the names of any connections or anything.
That “credential doesn’t exist” message while workflows still run is almost always a UI-vs-runtime credential resolution gap. Two things to check on self-host:
Credential rename without cache bust. If n8n-SharePoint was recently renamed or recreated, the workflow JSON references the old credential ID but the UI resolves by name; runtime picks up the ID (which still points to the new record), UI can’t. Restart the n8n container to force a re-resolve.
DB migration leftover. On self-host, a recent n8n upgrade sometimes leaves orphaned credentials_entity rows with mismatched nodesAccess. Check SELECT id, name, type FROM credentials_entity WHERE name LIKE '%SharePoint%' — if you see duplicates with different IDs, that’s it.
Long-term fix (and the reason self-host gets bitten by this more than cloud): if credentials live in an external gateway and n8n only holds a string reference, none of this state drift is n8n’s problem anymore. n8n stops caring whether “n8n-SharePoint” exists in its own DB — it just calls the gateway’s named endpoint.
We’re building the gateway piece in the open — DM if you want the writeup after you’ve unblocked the immediate issue.