We need to support a lot of customers (embbeding), with a lot of different flow.
Each customer (B2B) have his own credentials.
We need a secured way to run a flow only for specific customer. the current state of the platform is that we need to create a flow for each customer. this can be hundreds.
we also update and upgrade flows.
The current state of N8N is that you need to create flow for each customer which is a huge overload to develop such a thing, upgrade is also huge and tragic event.
Using expressions is not secured at all since you can see the credentials more than that there are way too many ways to use it : Oauth2/ ApiKey, etc…
I saw way too many tickets that have so many votes for this feature, but it seems like it is ignored.
I don’t want to add more links since the team is already aware for that.
Today we are in the middle of examining the platform with license for (embedded + enterprise) vs competitors, we like the platform but this feature is a must for us, otherwise its a huge overload on RnD team. I know some other platforms don’t support it too, some does support it and we examined them too.
Is this feature gonna be implemented soon? or neglected? (feature requests made from 2020 already)
I also need this but they way people request a solution above is bad and won’t work and possibly why it hasn’t been implemented yet… We shouldn’t allow ‘dynamic’ selection of credentials, instead I feel the best way to implement is as follows -
In the enterprise licence we can already create ‘projects’ which has their own ‘credentials’ for each ‘project’ - this is great and useful. We can replicate our master flow into each of these projects
THEN we introduce ‘local’ variables to each project - this is like global variables but only seen within the project and not to others. Local variables can be called the same thing like $myVar1 and used through any flow within the project.
THEN we create another master flow where we can do upgrades and enhancements and use the same variable of $myVar1 and once we copy and paste that flow into the project then the flow uses the local variables of the project.
This will mean that you can upgrade any flow and then copy and paste to deploy it on any project and it won’t break anything. It’s easy to maintain.
I was chatting to one of our product managers about this earlier this week and he may be about to pick up using expressions to dynamically select credentials to use in a workflow which would solve most of these requests.
Thanks Jon for the update. Though as part of our needs we moved to other solution. If you had it we might have chosen your solution cause we really liked that it is open source and deployable on K8S, also the SSO using SAML.
That is understandable, It takes time to pick up some features and they need a lot of ground work.
Maybe in the future once this has been implemented you can check it out again, One thing I would note is while our source is available it isn’t “open source”. Out of interest can you share what you went with in the end?
2 years later and I’m trying to see if I can figure out running a subflow to connect Microsoft Graph API multiple times for multiple customers.
I have OAuth2 credentials saved in n8n. What I had in mind approaching the problem was being able to pass the credential ID to use from main flow to subflow and have the subflow HTTP request look up that saved credential by ID.
@gregatbci for the Microsoft Graph API multi-tenant case, the workaround I use is storing each customer’s OAuth tokens (access_token, refresh_token, client_id, client_secret) in a database or encrypted key-value store, then retrieving them via a Code node at the start of the workflow. You then pass those values directly in the Authorization header of the HTTP Request node instead of using n8n’s saved credential object.
It’s not as clean as native credential switching, and you lose n8n’s automatic token refresh - so you’ll need to handle refresh logic in the Code node too. But it means one workflow serves all customers. Upvoted the feature request; this is a real gap for B2B embedding use cases.
@gregatbci you could use credential overwrites so clients can single click to sign in. Keep in mind though our license only allows for internal business use only, if you are using clients credentials you will likely need a license.
This is exactly where I’d avoid pushing raw tokens into the workflow.
The safer shape is: pass a client or workspace id into the reusable flow, resolve the saved credential in a runtime-owned boundary, then write a run receipt with client id, credential alias, workflow version, actor, and what changed. One flow stays reusable, but secrets and audit stay outside the editable workflow.