Use a shared connection only when the process is intended to act through that approved connection; use each user’s account when the action must operate under that person’s identity. This is an editorial decision rule, not a claim that either model is universally preferable or available in every edition.
Understand the documented identity distinction
The supplied n8n documentation says shared credentials can be used by others without those users viewing or editing credential details. It separately explains that sharing an end-user credential means users connect their own account rather than use the owner’s connection.
These are different identity arrangements. Hiding credential details does not, by itself, answer whose authority an action uses or how a connected service attributes it. Confirm those questions for the actual integration.
Sharing availability also differs between n8n Cloud and self-hosted editions, so identity design and edition verification must happen together.
Follow an identity-attribution decision tree
Start with the action, not the teammate who builds the workflow:
- Is this an organisational task with one approved connection owner? If yes, evaluate a shared saved credential.
- Must access depend on the participating individual’s account? If yes, evaluate end-user authorisation.
- Must records show which person initiated each action? If yes, define attribution evidence separately from connection ownership.
- Would a departing employee’s account disrupt the process? If yes, resolve ownership and continuity before implementation.
- Is the intended arrangement unsupported in the selected edition? If yes, redesign or pause rather than share passwords informally.
For privacy and rights review, ask who may authorise the connection and which records each identity should access. These are review questions, not legal conclusions.
Compare two hypothetical tasks
Imagine a hypothetical Hyderabad training organisation with two tasks. One publishes approved public course dates to a central test register. The other reads each instructor’s synthetic personal availability.
For the first, assess whether an organisation-controlled connection matches the task’s ownership. For the second, ask whether each instructor must authorise access independently. Neither answer follows merely from the fact that both tasks are automated.
Write an expected identity beside each action. Then inspect the available evidence from the connected service during a synthetic test. Pass only when the observed account and allowed scope match the design; unresolved attribution remains an exception.
Make identity a launch gate
Stop if the team cannot name the acting identity, connection owner and departure procedure. Next, verify the proposed model in the exact deployment using synthetic records.
If comparing the automation catalog, check access format and save terms before buying. Marketplace account, code or token offers are not proof of official subscription equivalence or the required sharing arrangement.
Sources and scope
Source material checked 29 October 2026; features/policies may change. The n8n credential-sharing documentation establishes sharing permissions, edition differences and the end-user identity distinction. The decision tree and hypothetical tasks are editorial advice.