n8n Access Control: Managing Team Permissions

Why access control becomes urgent the moment a second person joins

The first workflow you build in n8n is usually a solo act. You wire up a trigger, drop in a few nodes, test it against your own API keys, and ship it. Nobody asks who else can see it because nobody else is looking. That changes the moment a teammate joins the instance. Suddenly there's a marketing automation that touches your CRM, a finance workflow that reads your Stripe account, and an internal ops flow that pings your production database — all sitting in the same n8n instance, all potentially visible to anyone with a login.

Access control in n8n isn't a "nice to have" you bolt on later. It's the difference between a tool your team trusts with real business processes and a tool that quietly becomes a liability. A junior marketer who can edit a workflow that touches your payment provider isn't a hypothetical risk — it's a Tuesday afternoon accident waiting to happen. A contractor who still has credential access three months after their contract ended is the kind of thing that shows up in a security audit and makes everyone in the room uncomfortable.

This article walks through how n8n's permission system actually works — roles, projects, credential sharing, and the practical patterns that keep a growing team from stepping on each other or leaking secrets. If you're running community edition, self-hosting with a license, or on n8n Cloud, the concepts mostly transfer, though the exact feature set depends on your plan. We'll flag where that matters.

The three layers of n8n permissions

Before touching any settings, it helps to understand that n8n's access control operates on three distinct layers, and conflating them is the single most common source of confusion.

Instance-level roles control what a user can do across the entire n8n installation — things like managing other users, changing global settings, or installing community nodes. This is the coarsest layer and applies regardless of which workflow or project someone is working in.

Project-level roles (available on Team plans and self-hosted with the appropriate license) control what a user can do within a specific project — a named container for workflows, credentials, and shared resources. A person can be an admin on one project and have no access at all to another.

Resource-level sharing governs individual workflows and credentials — who can view, edit, or execute a specific one, independent of broader project membership in some configurations.

The mistake teams make is assuming instance-level role determines everything. It doesn't. Someone can be a low-privilege "member" at the instance level but still be a project admin with full control over a specific team's workflows. Thinking in layers, rather than one flat hierarchy, is the mental model that prevents most misconfiguration.

Instance roles: Owner, Admin, and Member

At the instance level, n8n ships with a small number of built-in roles.

• Owner — the account created during initial setup. There's exactly one, and it has irrevocable full control: user management, instance settings, billing (on Cloud), and every project. Ownership can be transferred but not deleted while it's the only owner.
• Admin — can manage users, invite and remove members, and adjust instance-wide settings, but typically cannot touch billing or transfer ownership. Admins are your day-to-day instance operators.
• Member — the default role for anyone invited. Members can create their own projects (if permitted), work within projects they're added to, and build workflows, but they have no instance-wide management power.

On paid tiers, n8n also supports custom roles at both the instance and project level, letting you define more granular permission sets — for example, a role that can view and execute workflows but never edit or delete them. If your organization has compliance requirements around segregation of duties (the person who builds automation shouldn't be the same person who approves it for production), custom roles are where you enforce that rather than relying on trust.

A practical rule: keep the number of Admins small. It's tempting to make everyone on the platform team an Admin "just in case," but every additional admin is another account that, if compromised, can rewrite instance settings or exfiltrate credentials. Two or three admins for a mid-sized team is usually plenty — everyone else should live at Member and get their real permissions through project roles.

It's also worth understanding what Admins *can't* do by default, because that boundary is often where teams get surprised. An Admin can typically invite and remove users and adjust global settings, but that doesn't automatically mean they can see every credential in every project — credential visibility still runs through project membership and sharing settings. Conflating "has admin rights" with "can see everything" is a common assumption that doesn't hold up once you actually test it. If your team is migrating from a flat, single-workspace setup to a properly layered one, budget time to test these boundaries deliberately rather than assuming they behave the way a similar tool (like a cloud IAM console) does.

Projects: the real unit of access control

If instance roles are the outer shell, projects are where meaningful access control actually happens. A project in n8n is a workspace that bundles workflows, credentials, and members together. Instead of one giant shared workspace where every workflow and credential is visible to every user (the old default in community edition), projects let you partition by team, by client, or by environment.

Common ways teams structure projects:

• By department — Marketing, Support, Finance, Engineering each get their own project. A marketing automation touching HubSpot has no business being visible to someone building an internal engineering tool.
• By client — agencies and consultancies running n8n on behalf of multiple clients keep each client's workflows and credentials in an isolated project, so cross-client leakage is structurally impossible rather than just discouraged.
• By environment — a "Production" project with restricted write access and a "Sandbox" or "Dev" project where anyone can experiment freely without risking a live workflow.

Within a project, members get one of three roles:

1. Project Admin — can add or remove project members, manage all workflows and credentials within the project, and change project settings.
2. Project Editor — can create, edit, and run workflows and credentials within the project, but can't manage membership.
3. Project Viewer — read-only access. Useful for stakeholders who need visibility into what an automation does without the ability to change it.

Here's the pattern that works well in practice: create a project per functional team, make one or two senior people on that team Project Admins, add the rest of the team as Editors, and give any manager or stakeholder who just needs visibility the Viewer role. This mirrors how most teams already think about access in tools like Notion or Google Drive, so it requires almost no explanation when you roll it out.

It's worth thinking about projects as long-lived organizational units, not one-off containers you create and forget. As your automation footprint grows, a project accumulates workflows, credentials, and history, and it becomes the natural unit for reporting too — "how many workflows does Finance own, and how many failed last week" is a question you can answer cleanly if Finance workflows all live in one project, and a much messier one if they're scattered across a single shared workspace. When you're deciding how granular to make your projects, err on the side of fewer, well-named projects rather than a project per individual workflow. A project per person or per workflow just recreates the sprawl you were trying to escape, with extra administrative overhead on top.

One more nuance worth calling out: a user can belong to multiple projects simultaneously, with a different role in each. A senior automation engineer might be a Project Admin on the Engineering project, an Editor on the Marketing project where they're helping build a lead-scoring workflow, and a Viewer on the Finance project because they occasionally need to check whether an integration is still running. This flexibility is what makes the project model scale past the first few teams — it lets access map to actual working relationships instead of forcing every person into a single fixed bucket.

Sharing workflows without oversharing credentials

One of the most common mistakes is treating "sharing a workflow" and "sharing a credential" as the same action. They are not, and n8n deliberately keeps them separate.

When you share a workflow with another user or project, you're giving them visibility and (depending on role) edit access to the node structure, the logic, and the execution history. You are not automatically giving them the ability to see the underlying credential secrets that workflow uses. Credentials in n8n are their own object with their own sharing settings, and by default a credential is only usable by the person who created it unless it's explicitly shared.

This separation matters because it lets you do something genuinely useful: let a teammate view or even edit the workflow logic — the branching, the conditions, the transformations — without ever exposing the API key or OAuth token that workflow depends on. Someone can debug why a Slack notification isn't firing without ever seeing the Slack bot token.

Practical guidance for credential sharing:

• Share credentials to a project, not to individuals, wherever possible. It's easier to audit "who has access to the Stripe credential" when the answer is "everyone in the Finance project" rather than a scattered list of individually-granted users.
• Use separate credentials per environment. Don't reuse the same Postgres connection string credential across your Dev and Production projects. If a junior developer breaks something in Dev, you don't want that blast radius extending to production data.
• Rotate credentials when someone leaves a project, not just when someone leaves the company. Contractors and cross-team collaborators often need temporary access to a credential for a specific integration; when that need ends, the sharing should end too.
• Avoid the "shared admin credential" trap. It's common early on to have one person set up the master Google Workspace or AWS credential and share it with the whole team because it's convenient. This works until someone needs the exact same credential revoked for one person but not others — which isn't possible if it's a single shared object. Prefer service-account-style credentials scoped narrowly to what the workflow needs, rather than reusing a personal, broadly-privileged one.

Setting up SSO and provisioning for larger teams

Once you're past a handful of users, manually creating accounts and assigning roles in the n8n UI becomes both tedious and error-prone — new hires get added late, offboarded employees linger, and role drift creeps in as people move teams without their permissions being updated.

n8n's enterprise-tier plans support SAML-based SSO, letting you connect an identity provider like Okta, Azure AD, or Google Workspace. This buys you two things beyond convenience:

• Centralized deprovisioning. When someone leaves the company and IT disables their identity provider account, their n8n access disappears with it, rather than depending on someone remembering to also revoke n8n access separately.
• Consistent role mapping. You can map identity provider groups to n8n project roles, so "add this person to the Finance-Automation group in Okta" automatically makes them a Project Editor on the Finance project in n8n, no manual step required.

If SSO isn't available on your plan or you're self-hosting community edition, the fallback is discipline: maintain an actual list (a spreadsheet is fine) of who has access to which project and which credentials, review it monthly, and treat offboarding as a checklist item that includes "remove from n8n" every single time. The tooling gap doesn't excuse skipping the process — it just means the process is manual instead of automatic.

Auditing: knowing who did what

Access control isn't only about preventing access — it's also about being able to answer "who changed this workflow, and when" after the fact. n8n's execution log gives you a per-workflow history of runs, inputs, and outputs, which is useful for debugging but limited for security auditing since it doesn't fully capture *who edited the workflow definition itself*.

For that, enterprise plans expose audit logs covering user management events, credential access, and workflow changes at the instance level. If you're on a plan without dedicated audit logging, a few workarounds help close the gap:

• Use source control for workflow definitions. n8n supports exporting workflows as JSON and increasingly supports git-based syncing on enterprise tiers. Even a manual habit of exporting critical workflows to a git repo after major changes gives you a diffable history that the UI alone won't.
• Restrict edit access on production-critical workflows to a small, named set of people. If only two people can edit the Stripe reconciliation workflow, "who changed it" is a much shorter list to investigate when something breaks.
• Pair workflow changes with your existing change-management process. If your team already requires a Slack message or ticket for production deploys, extend that norm to n8n workflow edits touching sensitive systems. The tool doesn't need to enforce this — the team culture can.

Common access control mistakes and how to avoid them

A few patterns show up repeatedly in teams that get burned by loose n8n permissions.

• Everyone is an Owner or Admin. Early-stage teams often add every early employee as an instance Admin because nobody's thought about the model yet. Fix this by doing a role audit now: demote everyone except the two or three people who genuinely need instance-wide control.
• One giant shared project for the whole company. This defeats the purpose of projects entirely. If your instance still has a single default project with every workflow and every credential in it, plan a migration to department- or client-based projects, even if it takes a few weeks to do gradually.
• Personal credentials embedded in shared workflows. Someone builds a workflow using their own personal API key "temporarily" and it's still there a year later, shared with the whole team, tied to an account that might get deactivated at any time. Replace personal credentials in shared workflows with service accounts as soon as a workflow moves from prototype to production use.
• No offboarding checklist. People leave, their n8n account lingers, and their credentials stay shared. Add "revoke n8n access" to your standard offboarding checklist, and if you're on an enterprise plan, wire this into SSO deprovisioning so it happens automatically.
• Treating workflow sharing and credential sharing as the same toggle. As covered above, they're separate. Double-check that sharing a workflow for visibility hasn't also inadvertently exposed a credential that should stay locked down.
• No separation between Dev and Production. Testing directly against production credentials because "it's just a quick change" is how a bad regex ends up mass-emailing your customer list. Separate projects with separate credentials cost a few minutes to set up and save you from a very bad day.

Building the habit, not just the configuration

None of this works as a one-time setup. Access control is a living part of how your team operates, and it needs the same maintenance as any other piece of infrastructure. A few habits make it stick:

• Review project membership quarterly. People change teams, projects get deprecated, and access that made sense six months ago often doesn't anymore.
• Default to least privilege for new members. Start everyone as a Viewer or Editor on the specific project they need, not Admin "to save time." It's much easier to grant additional access later than to discover, after an incident, that someone had far more reach than their role required.
• Document your project structure somewhere outside of n8n itself. A short internal doc listing each project, its purpose, and who owns it means new hires and auditors don't have to reverse-engineer your access model from the UI.
• Treat credential creation as a reviewed action for sensitive systems, not a self-service action anyone can take. If a workflow needs a new production database credential, that's worth a second pair of eyes before it's created and shared.

Getting this right doesn't require exotic tooling — it requires treating your automation platform with the same seriousness you'd apply to your codebase's access controls or your cloud provider's IAM policies. n8n gives you the primitives — instance roles, projects, resource-level sharing, and (on higher tiers) SSO and audit logs. The rest is discipline: naming projects sensibly, keeping credentials scoped and rotated, and reviewing who has access on a schedule instead of only after something goes wrong.

If you're building automation workflows that increasingly touch real business systems — CRMs, payment processors, internal databases — access control stops being an afterthought and becomes part of the architecture. Understanding roles, projects, and credential boundaries early means you're not retrofitting security onto a tangle of shared workflows later, when the stakes and the headcount are both higher.

If you want to go deeper on building production-grade automations in n8n — including how to structure workflows, manage credentials safely, and combine n8n with AI agents for real business use cases — check out the n8n AI Agent Tutorial course on teachyou.ai. It walks through practical, real-world workflow design with the same rigor this article applies to access control, so the automations you build are not just functional but safe to hand off to a whole team.