Feedback: Feature requests for better team development in n8n

Feature Requests
1

The idea is:

I would like to see improvements in how n8n handles workflows that are being worked on by multiple people. Right now I see the following limitations:

  • When someone shares a workflow, those who are shared on the workflow can not in turn share again, only the owner can.
  • When someone creates a data table and incorporates it into a workflow that in turn gets shared, whoever that workflow is shared with can not update the data table schema, and it is not possible to directly share a data table
  • With credentials, I can not create a new element in a shared workflow that uses an existing credential created by the owner of the workflow, I have to create my own. This creates the potential for a single workflow that depends on multiple credentials owned and managed by multiple people.
    The result of this is that even if workflows are shared, the elements that the workflows rely on depend on a single person to make changes for each of those dependencies. If work is shared across the team, this creates repeated single points of failure for managing development.

My use case:

I have multiple workflows being worked on by multiple people in my team. We can split up the workflows into small chunks so that one person can focus on a workflow, but if that person is away or busy, and that person shares the workflow, I need for all the resources that the workflow depends on to also be manageable by the person I’ve shared that workflow with. It would be better if we can have elements owned by a team rather than a person so that we can better manage development across a team.

I think it would be beneficial to add this because:

The current architecture behind workflow and resource sharing does not scale to a collaborative or team setup. It also results in duplicate resources being created in the event the original workflow owner is not available.

Any resources to support this?

Are you willing to work on this?

I am not able to personally work on code enhancements however I am happy to provide input on functionality.

2

The credential ownership issue is the one that hits hardest in practice - when the original owner leaves or changes roles, every workflow that depends on their credentials becomes a single point of failure. The same issue applies to the data table schema access you described. Both would need a cleaner permissions model where ownership can be transferred or team-scoped rather than tied to the creating user. Worth upvoting this one.

3

You’ve nailed the root cause here. The ownership model in n8n CE is user scoped, not team scoped, and that’s why every problem you listed feels like the same problem, because it basically is.
A few things that might help in the meantime:
On credentials, sharing is a paid feature so there’s no clean fix in CE. What a lot of teams do instead is move away from personal OAuth tokens toward service account credentials at the integration level. For Google services especially, a service account credential doesn’t expire when someone rotates their password or leaves the team. It doesn’t fix how n8n handles ownership internally, but it removes the most painful version of the problem where a workflow breaks because it’s tied to one person’s account.
On data tables, tables inside a Project are shared with everyone in that project, but Projects are a paid plan feature. In CE you’re in Personal workspace only, so tables stay with their creator. Most teams end up moving persistent data outside n8n entirely, something like supabase or a self hosted postgres that everyone can access independently of n8n’s permissions.
On re-sharing, there’s genuinely no workaround in CE. Instance admin or original owner, that’s it.
The proper fix for all of this is n8n’s projects and RBAC system, which is what it was built for. It kicks in from starter cloud or business self-hosted. Whether that’s worth it for your situation is a different question.

4

Thanks all. In our case, we are self-hosted, I’m not sure what that means in terms of the options available to us. Yes credentials can be tied to team credentials (which is what we are doing for our particular example) but unfortunately we are still hampered by the credential sharing limitation within n8n itself.

For data tables, yes externalizing the data table outside of n8n will help somewhat in that you could have multiple people with access to that externalized data source, but then you still need a credential to access so we only fix part of the problem, but at the cost of the ability to quickly prototype things that might need some sort of local data store.

Ultimately to make this work in a team context, n8n would need to adopt a more team-centric approach with RBAC and resource assignment and sharing.

5

CE and self-hosted Business are actually different things.

With CE (what you’re running), your assessment is correct. Credential sharing is a hard limitation. Service accounts help with password rotation and offboarding, but they don’t change who can use a credential in the editor.

Self-hosted Business runs the same Docker image but unlocks Projects, RBAC, team credential sharing, and proper ownership. That’s what would solve the issue you’re describing. The downside is the added license and execution costs.

You’re also right about data tables. Moving data outside n8n solves the access problem, but adds another credential dependency and makes quick prototyping less convenient.

So your conclusion is basically spot on: CE wasn’t built for team-level resource management. That’s intentionally part of the paid offering. The real question is whether the friction you’re seeing is worth the Business license cost.

1 Like