Dynamic Credential Selection via Expressions for Multi-Tenant Workflows

[tony2]

<!- Problem Statement
Currently, credentials in n8n nodes must be selected statically at design time. This creates a major scalability issue for multi-tenant workflows where you need to interact with the same service (e.g., Google Calendar, Outlook, Gmail) using different credentials for different users/partners. (This issue is a generalization of: Seeking Advice on Implementing Dynamic Google Calendar Credentials for Multi-User Workflows in n8n - #2 by solomon )
Real-World Use Case
I manage a workflow that sends calendar events to hundreds of partners’ calendars (Outlook/Gmail). Each partner has their own credential stored in n8n.
Current workaround:

• Create a Switch node with hundreds of branches
• Create hundreds of duplicate calendar nodes (one per partner)
• Each node has a statically selected credential
• Result: Unmaintainable workflow that scales extremely poorly
  What I need:
• A single calendar node that dynamically selects credentials at runtime
• Credential selection via expression: ={{ $json.partnerId }} or ={{ $json.credentialName }}
  Current vs. Desired Workflow
  Current (doesn’t scale):
  Trigger
  → Get Partner Data
  → Switch Node (100+ branches)
  → Calendar Node 1 (Partner A credential)
  → Calendar Node 2 (Partner B credential)
  → Calendar Node 3 (Partner C credential)
  → … (100+ more nodes)
  Desired (scalable):
  Trigger
  → Get Partner Data
  → Calendar Node (credential: ={{ $json.partnerCredentialId }})
  → Create Event
  Proposed Solution
  Allow credential selection fields to accept expressions, similar to how other node parameters work:
  Option 1: Credential ID
  Credential: ={{ $json.credentialId }}
  Option 2: Credential Name
  Credential: ={{ $json.credentialName }}
  Option 3: Credential Selector with Expression Support
  Credential Mode: Expression
  Credential Expression: ={{ $json.partnerCredentialId }}
  Security Considerations
• Credentials would still be pre-created and stored securely in n8n
• No credential data would be exposed in expressions
• Only credential IDs/names would be referenced dynamically
• Existing permission models would still apply
• Could add optional restrictions (e.g., limit which credentials a workflow can access)
  Benefits

1. Scalability: Single node handles unlimited partners/tenants
2. Maintainability: One node to update instead of hundreds
3. Flexibility: Add new partners without modifying workflow structure
4. Performance: Smaller workflow JSON, faster loading
5. Common Pattern: Enables true multi-tenant SaaS workflows
   Who Would Benefit

• Agencies managing multiple client accounts
• SaaS platforms with multi-tenant architectures
• Integration platforms connecting to multiple user accounts
• Automation providers serving multiple customers
• Enterprise users with multiple department/team credentials
  Affected Nodes
  This would benefit any node that uses credentials, especially:
• Google Calendar, Gmail, Google Sheets, Google Drive
• Microsoft Outlook, Teams, OneDrive
• Slack, Discord, Telegram
• CRM systems (Salesforce, HubSpot, etc.)
• Database connections
• API authentication nodes
  Related Discussions
  This appears to be a common pain point in the community. Similar requests or workarounds have been discussed, but no native solution exists yet.
  Questions for the Team

1. Is this technically feasible with the current architecture?
2. Are there security concerns that would need to be addressed?
3. Would this be a breaking change, or could it be added as an optional feature?
4. Is there a timeline or roadmap consideration for credential management improvements?
   Thank you for considering this feature request! This would be a game-changer for multi-tenant workflows and would significantly expand n8n’s capabilities for enterprise and SaaS use cases.

The idea is:

Allow for “expression based” Credential selection/injection on any node supporting credentials

My use case:

Share u​ Real-World Use Case
I manage a workflow that sends calendar events to hundreds of partners’ calendars (Outlook/Gmail). Each partner has their own credential stored in n8n.
Current workaround:

• Create a Switch node with hundreds of branches
• Create hundreds of duplicate calendar nodes (one per partner)
• Each node has a statically selected credential
• Result: Unmaintainable workflow that scales extremely poorly
  What I need:
• A single calendar node that dynamically selects credentials at runtime
• Credential selection via expression: ={{ $json.partnerId }} or ={{ $json.credentialName }}se cases to help us understand better.

I think it would be beneficial to add this because:

What​ Benefits

1. Scalability: Single node handles unlimited partners/tenants
2. Maintainability: One node to update instead of hundreds
3. Flexibility: Add new partners without modifying workflow structure
4. Performance: Smaller workflow JSON, faster loading
5. Common Pattern: Enables true multi-tenant SaaS workflows
   Who Would Benefit

• Agencies managing multiple client accounts
• SaaS platforms with multi-tenant architectures
• Integration platforms connecting to multiple user accounts
• Automation providers serving multiple customers
• Enterprise users with multiple department/team credentials problem will this new feature solve?

Any resources to support this?

Are you willing to work on this?

Don’t forget to upvote this request. The more votes this Feature Request gets, the higher the priority.

[Pranoy123]

Hey @tony2 I ran into this exact same scaling issue when building out multi-tenant workflows and a Switch node with hundreds of branches is not only impractical but also a nightmare to manage.

While we wait for n8n to potentially add expression support to native credential selection, there is a very clean workaround that lets you achieve exactly what you want (a single scalable node that handles unlimited partners).

The trick is to abandon the native service nodes entirely and swap them out for HTTP Request nodes. Here is how you can structure it:

• Trigger / Fetch Partner Data: Pass your partner data (including their specific access_token or API key) into the workflow dynamically via a Webhook or Database fetch.

• Iterate (if batching): Use a Loop node if you are processing multiple partners in a single run.

• Make the API Call: Instead of the native Google Calendar node, use an HTTP Request node pointing to the Google Calendar API endpoint. In the Headers section, you can use expressions to map the token dynamically into the Authorization header (e.g., Bearer {{ $json.partnerCredentialId }}).

To make this work, you’ll need a frontend or web app that connects to your webhook to handle storing and sending data to your workflows.

For your specific use case, this means having a web app where users log in, provide their credentials like logging into Google or their calendar API key etc, and trigger the workflow themselves. Alternatively, if you want to manage everything behind the scenes, you can store all user credentials in your own database. Then, you just run a function that fires those credentials to your n8n webhook—either iterating one by one or passing them altogether in an array.

Hopefully, this points you in the right direction! If this architecture sounds good for your use case, let me know and I can share a few more resources.