Verify credential sharing for the exact n8n edition and deployment you intend to use before making it a dependency of team automation. The supplied documentation says availability differs between n8n Cloud and self-hosted editions; it does not justify assuming identical access or permissions across all options.
Define the collaboration requirement first
“Team access” is too vague to serve as a specification. Separate the person who owns the connection, the people who need to use it, and anyone expected to maintain its authentication details.
n8n documents that shared credentials can be used by others without those users viewing or editing credential details. That distinction matters when writing a handover plan: permission to use a connection is not the same requirement as permission to maintain it.
Also distinguish shared saved credentials from end-user authorisation, where users connect their own accounts rather than use the owner’s connection.
Complete an edition-verification questionnaire
Record answers and dated evidence for these questions:
- Is the proposed deployment n8n Cloud or self-hosted?
- What exact edition or entitlement is being evaluated?
- Is credential sharing documented as available for that arrangement?
- Who must use a saved connection, and who must maintain it?
- Does the requirement involve one saved connection or separate user accounts?
- What happens operationally when the connection owner leaves?
- Which permission assumptions remain unverified?
- Who is responsible for checking the arrangement before rollout?
Do not fill gaps with descriptions from a different edition. Mark uncertain answers “unverified,” with a named person responsible for resolving them.
Apply a hypothetical three-person review
Suppose a hypothetical Ahmedabad agency has one connection owner, one workflow builder and one support operator. Its requirement is that the builder and operator can use an approved test connection without viewing its secret.
The review should check that specific requirement in the proposed deployment. It should separately establish who can update authentication details when maintenance is needed. A successful demonstration of use does not settle maintenance responsibility.
Evaluate with synthetic records and approved test access. Pass only when each required role has evidence for its intended activity and no essential permission remains assumed. Do not distribute a shared password to make the demonstration work.
Separate provider capabilities from purchase terms
Provider documentation establishes product behaviour within its stated scope. A marketplace listing establishes only the offer terms it actually states; its title is not evidence of edition entitlement.
If considering the automation catalog, check access format and save terms before buying. Marketplace account, code or token offers are not proof of official subscription equivalence. Stop purchase or design approval if credential-sharing availability is essential but unverified; next, obtain evidence for the exact arrangement.
Sources and scope
Source material checked 29 October 2026; features/policies may change. The n8n credential-sharing documentation establishes edition differences and sharing distinctions. The questionnaire, role review and purchasing gates are editorial advice, not an edition-availability list.