Skip to main content
Docs
Feature Requests Onboarding Trust Center Status Page

Community

Destination Improvement: Override Snowflake Role Per Connection

Not planned
Marta Frąckowiak User

Hello Fivetran Team,

I’d like to request a feature that allows overriding the Snowflake role at the connection level (in the same way this is currently supported for warehouses), instead of being restricted to a single role defined at the destination level.

Currently, the Snowflake role is configured only in the destination settings, which means all connections using that destination must share the same role. This creates challenges when:

  • Teams want to enforce stricter least-privilege access

  • Ownership of data products is separated across teams with different administrator roles

Proposed enhancement:
Allow each connection to optionally specify its own Snowflake role, which would override the destination-level role for that specific connection.

Benefits:

  • Better security through least-privilege access

  • More flexible permission management

  • Easier compliance with internal governance policies

  • Reduced need to create multiple destinations just to vary roles

This would significantly improve flexibility for teams operating in more complex Snowflake environments.

Thanks for considering this request, and we’d be happy to provide more context if helpful.

Please sign in to leave a comment.

Comments

3 comments

Date Votes
  • Egidio Terra Fivetranner

    Hi Marta,

    Thanks for submitting this request.

    This feature—overriding the Snowflake role per connection—is not currently on our roadmap. All settings required by Fivetran to load data, including Snowflake role, are managed in the destination configuration. During setup, we validate and test all credentials and permissions at the destination level, so our current system does not support specifying connection-level roles directly.

    To help us better understand your needs, could you share more details about your compliance requirements? Specifically, are there any external compliance rules that require you to have a different role per connection, or is this mainly to support internal governance or operational preferences? Further details on your use case would help us in prioritizing potential enhancements or evaluate alternative designs.

    Best regards,

  • Marta Frąckowiak User

    Hi,

    Thank you for the clarification and for asking for more details.

    Our main motivation for requesting per-connection Snowflake roles is primarily internal governance and operational management, rather than external compliance rules. Specifically:

    • Least-privilege enforcement: Different teams or projects should only have access to the data they manage, without sharing a single role across all connections.

    • Separation of ownership: Multiple teams manage different data products in our Snowflake environment, each with different administrative roles. A single destination-level role can create operational and security challenges.

    • Operational flexibility: Currently, to accommodate different roles, we need to create separate destinations, which increases management overhead.

    It’s worth noting that in dbt, this kind of role override per connection/project is already supported, and we are actively using it. Allowing Fivetran to support a similar approach would align with established patterns and simplify governance in more complex Snowflake environments.

    I hope this helps clarify the use case. We’d be happy to provide further context or examples if that would be helpful for evaluating potential enhancements.

    Best regards,
    Marta

  • Egidio Terra Fivetranner

    Hi Marta,

    We’re revisiting this requirement and wanted to clarify one additional point. If you’re using multiple connectors, the configuration can become quite large and harder to manage over time. As an alternative, you could consider creating multiple destinations for the same database, which is typically easier to maintain.

    We’re also working on introducing query tagging for Snowflake, which will help attribute queries to distinct groups of users.

    Would there be any limitations on your side when it comes to creating separate destinations?

     

    Best,