Strategic call Picture a Slack assistant your whole team uses. Anna asks it to post an update, Ben asks it to find a file. Behind the scenes, both requests ran on the same Slack account: the one the builder connected when they set up the workflow. Every message looked like it came from the builder, every search saw what the builder could see, and afterwards nobody could tell who actually asked for what.
With end-user credentials, Anna’s request runs with Anna’s account and Ben’s with Ben’s. Same workflow, but the identity follows the person who triggers it.
The problem: every automation borrowed one login
For years, a credential in n8n was fixed: connected once and used for every run, whoever triggered it. That works fine for background jobs. It becomes a problem the moment real people start using your workflows and agents.
- Wrong identity. Actions show up under the builder’s name, not the name of the person who asked.
- Too much access. Everyone who uses the workflow borrows the builder’s permissions, including data they should never see.
- No real audit trail. You cannot see who did what, only that the builder’s account did it.
- Fragile. When the builder leaves or changes a password, the workflow breaks, or keeps access it should no longer have.
What end-user credentials change
When you set up a credential in n8n, you now choose a credential type:
- Fixed credential. The same account is used no matter who runs the workflow. This is still the default.
- End-user credential. Each person connects their own account, and n8n uses that account when they trigger the workflow. Their connection is visible only to them.
The builder sets up the connection once, as a template. For a service such as Gmail or Slack, that means the app details. Every person who uses the workflow then connects their own account through that template. From then on, a run triggered by Anna reads Anna’s inbox, and a run triggered by Ben reads Ben’s.
Where it works
End-user credentials work on the triggers where a real person starts the run:
- MCP Server trigger. When someone uses your n8n tools from Claude or another AI assistant, the tools act with that person’s own accounts.
- Form trigger. A colleague submits a form, and the follow-up happens in their name, in their own tools.
- Hosted Chat trigger. A chat assistant answers and acts with the access of the person chatting with it.
What you can build with it
- One AI assistant for the whole team. A single agent, connected through the MCP Server, that works with each person’s own calendar and inbox. Built once, useful for everyone, without sharing a mailbox.
- Requests that stay in the right name. A form for expense claims or leave requests that files documents in the requester’s own drive and sends the email from their own account.
- CRM updates by the right person. A chat assistant that logs notes and updates deals as the sales rep who asked, so your reporting stays correct.
- Access that matches reality. Someone who cannot open a document in Google Drive cannot open it through the workflow either.
Fine-grained access, too
End-user credentials arrive together with more control over who can do what inside n8n itself: custom instance roles, role mapping from your identity provider inside n8n, and roles you can manage through the API. Together they make it much easier to give every person exactly the access they need, and nothing more. Next up: agents with an identity of their own.
Why this matters for governance
One of the biggest governance risks we see is automations and agents running on one person’s login. In our governance framework, access is the first pillar: who is acting, and what can they do? With end-user credentials, the answer becomes simple. The person who triggers the run is the one acting, with their own permissions.
- Least privilege by default. Nobody gets more access through a workflow than they already have.
- A trail you can trust. Every action can be traced to the person who triggered it.
- Clean offboarding. When someone leaves and their account is closed, their access through your workflows goes with it.
- Better privacy. Personal data stays with the person it belongs to, which makes it easier to stay in line with the GDPR.
Before you switch
- It is in preview. End-user credentials are an Enterprise feature on n8n Cloud and self-hosted, and n8n marks them as preview. Test them first, and do not rely on them yet for business-critical workflows.
- Not every workflow has a person behind it. Scheduled jobs and background syncs still need a fixed credential. Give those a dedicated service account, not someone’s personal login.
- Everyone connects once. Plan a short onboarding moment, so people connect their accounts before they need the workflow, not halfway through a task.
- Check the scopes. Every connection goes through the same template, so the app behind it needs the right permissions. A missing scope breaks the workflow for everyone who connects.
How we help
As an official n8n Ambassador, Marrallisa follows n8n’s identity and governance roadmap closely. We review which of your workflows should move to end-user credentials and which should stay on a service account, and we set up the connections, roles and scopes so your team can start without friction. Read how we govern automations, see our automation service, or catch up on n8n’s new engine and governance roadmap.
Frequently asked questions
What are end-user credentials in n8n?
A credential type that is resolved per person when a workflow runs. Instead of one shared account, each user connects their own account, and a workflow or agent they trigger runs with that account.
Which n8n triggers support end-user credentials?
The MCP Server trigger, the Form trigger and the hosted Chat trigger: the triggers where a real person starts the run.
Do I need n8n Enterprise?
Yes. End-user credentials are part of the Enterprise plan, on n8n Cloud and self-hosted. The feature is in preview and may still change.
Should all my credentials become end-user credentials?
No. Use them where a person triggers the run and should act as themselves. Scheduled jobs and background processes have no person behind them, so they keep a fixed credential on a dedicated service account.