we run n8n Cloud Enterprise and manage roles through the public API. We have built our own custom roles with tightly scoped permissions, but we keep hitting a wall with the built-in system roles.
The built-in roles (project:admin, project:editor, global:admin, etc.) come with a fixed set of scopes that we cannot change. The API rejects any modification: PUT on a systemRole: true role returns 400 “Cannot update system roles”, and DELETE returns “Cannot delete system roles”. There is also no active/enabled flag on the role object.
In practice this means n8n dictates the exact permission bundle for these roles, and we cannot tighten or remove individual permissions from them. Since the built-in roles are always assignable, a project admin can grant a role that carries permissions we specifically want to withhold (for example, publishing), and we have no preventive control over it, only a reconcile-after-the-fact workaround.
Questions:
Is this limitation intended? Are the permissions of built-in roles meant to be immutable by design?
Is there any supported workaround to restrict or override individual permissions within a built-in role, or to prevent specific built-in roles from being assignable by non-instance-admins?
If not currently possible, is customisable built-in-role scopes (or disabling/hiding built-in roles) on the roadmap, and any timeline?
Would be great if somebody could share how they solved it cause from my current point of view this block proper platform governance.
Yes, this is intentional. Roles with systemRole: true are immutable. The public API explicitly supports updating and deleting custom roles only, so the 400 responses are expected.
There is currently no supported way to remove scopes from a built-in role, hide it, disable it, or restrict which target roles a project admin may assign.
For manual role management, the practical boundary is to avoid assigning project:admin. Give the user a custom project role without workflow:publish and without permission to manage project members.
Cloud Enterprise also has a preventive option through SSO. Set Role assignment to Instance and project roles via SSO, then use Map rules inside n8n. In that mode manual role assignment is disabled, so project admins cannot grant themselves or others one of the built-in roles. Your mapping rules become the source of truth and can assign your custom roles.
Be aware that access missing from the mappings is removed at the user’s next login, so export the offered CSV before enabling it.
I could not find a public roadmap item or timeline for customising or disabling system roles. Since you are on Enterprise, that part needs confirmation through your dedicated support channel.
For the API side, the scope to leave out of that custom project role is project:manageMembers. It’s the only check on every add, re-role and remove member endpoint, so a role without it can’t hand out anything.
One gotcha since you run custom instance roles: give them user:list (Users > View) or a project admin’s Add members search comes back empty. That’s open right now as 36963.
I was afraid that this is the case and already explored the suggestions you provided. The problem is that if I don’t let project admins manage project members who is doing it then? The idea is that n8n lets users automate processes in their projects, if they can’t maintain their members that creates a bottleneck elsewhere.
Using role mapping is unfortunately not an option either. The only app that consumes n8n project role memberships is, well, n8n. So managing those memberships on the IDP does not make a lot of sense and would push me to build another kind of self service or hundrets of groups for it, thats not feasible.
From my understanding that limitation is a big blocker to simplify the project management for little to know benefit. What’s even the benefit of immutable roles? If n8n would like to stick to the approach at least add a permissions scope to custom roles like “can_assign_builtin_roles” so the restriction problem would be solved.
Just a thought. For the time being I seem to require some kind of monitoring for it which is not ideal.
@magichappenz You are right. My workaround moves member management somewhere else, so it does not solve the delegated project admin requirement.
Right now n8n does not separate managing project members from choosing which project role they may receive. There is no allowlist for assignable roles, and API monitoring can only detect and revert an assignment after it happens.
Your can_assign_builtin_roles idea addresses that gap. An allowlist of role slugs would be even more flexible, since project admins could assign approved custom roles without being able to grant project:admin.
Since you are on Cloud Enterprise, I would raise this exact requirement through your CSM or support channel as a product gap. I still cannot find a public roadmap item or timeline for it.