Role-Based Access Control

Overview

Role-Based Access Control (RBAC) is a permission management system that restricts access to Fivetran resources based on user roles. Each user is assigned a role that determines what they can view or manage. RBAC ensures users have access to resources according to their work responsibilities.

In our RBAC model, we provide a set of standard and custom roles to grant or deny access to different Fivetran resources within the Fivetran account:

• Account
• Destinations
• Connections
• Transformations

The user roles also manage permissions for related areas of each resource, like Usage and Billing for the Account resource, or Logs and Transformations for the Destinations resource.

Standard roles in our RBAC model

Fivetran’s RBAC model supports fine-grained, hierarchical access control across three main resource types, listed from highest to lowest:

• Account
• Destination
• Connections

Roles assigned at a higher level cascade down. For example, an account-level role may include permissions to manage all destinations and connections, while a connection-level role cannot access account-level settings.

See our Role Permission Matrix Tables documentation to learn more about the permissions of each standard role available in our role-based access model.

The following table lists the user roles in our RBAC model:

*NOTE: These roles are only available on the Enterprise or Business Critical plan.

RBAC model benefits

The following team structure is typical for enterprise customers' organizations:

• A core data team manages a central destination within the organization's Fivetran account.
• One or more teams manage centralized destinations, such as Snowflake, and are responsible for the data that lands in the destinations.
• One or several project or operational teams need to manage their specific data sources.

RBAC addresses common enterprise data governance challenges:

• Fast access: Project and operational teams get immediate access to the data they need - without delays caused by dependency on core data teams.
• Reduced burden: The data team avoids the overhead of manually handling access requests at scale.
• Granular control: Permissions can be precisely scoped to meet enterprise compliance and security requirements.

Our RBAC model introduces the following entities and features:

• Teams let you scale role and permission management across a large number of employees easily, while not affecting an individual employee's role and permissions. Delegating permissions from account-level user and team roles to users and teams — scoped per destination or connection — along with support for custom role creation and assignment.
• The Destination Creator and Create Connection roles automatically give you and your team members control over the destinations or connections you or your team create. This access automation lets you eliminate any waiting time for the approval by the central data team and independently manage access permissions for the resource right after its creation.

Our RBAC model works as follows:

1. Account administrators manage the entire account. They add users with the Destination Creator or Manage Destination role for existing destinations.
2. Users with the Destination Creator role can create and manage destinations they add.
3. Any user with the Manage Destination role can add teams that need to sync data to the destination.
4. Each team has a team manager who adds users to the team as team members, or remove them from the team.
5. Team roles in account, destinations, and connections allow delegating permissions in the corresponding resources in the same way as user roles do. This means that teams also don't have to rely on users with Manage Destination or Account Administrator roles to manage memberships. In turn, users with the Manage Destination role don't have to rely on Account Administrators to create destinations or add teams.

How we recommend using our RBAC model

Account permissions

1. Get a list of users who need access to the entire account.
2. Set up a team and add these users to the team.
3. Set the team's role to Account Administrators.

Destination permissions

1. Get a list of users who need to set up their own destinations.
2. Map the list of destinations to the list of users who need to manage it.
3. Create a team per destination or a set of destinations.
4. Assign the team to each of those destinations.

Connection permissions

1. Get a list of connections syncing data to Fivetran.
2. Get a list of teams who own those connections and map them out.
3. Get a list of managers for those teams.
4. Set up teams and associate connection level permissions.

Custom roles in our RBAC model

We provide a set of standard user roles that have preset and fixed access scope and one or several permissions.

We also support custom user roles where you can modify both the access scope and resource area permissions.

RBAC permissions

The following table describes the permissions we use in our RBAC model:

The following tables show the list of permissions used for each resource area.

Account permissions

Destination permissions

*NOTE: The custom role must have Account Access enabled to create destinations.

Connection permissions

You can grant the user role access to either All, Selected connection types, or None.

For connections, you can select one of the following permissions:

• Manage
• Create
• Edit
• View

Teams

Teams allow you to organize users into logical groups that reflect your organizational structure, including external contractors. Teams simplify permissions management across destinations and connections by letting you assign roles to groups instead of individuals.

Account Administrators and Team Managers can add users to one or multiple teams. Each team has a standard or custom role in the account and one or several destinations as well as for each connection in the destinations. For each team member, the team role extends the account permissions and group/destination permissions, including the connection permissions that the team member is assigned as an account user. For example, if your role in the destination has View permissions for all connections, and your team role has the Manage permission for all connections, then you can manage all connections in the destination.

A team can be assigned permissions to create a destination. A team is assigned the Manage Destination role for any destination it creates. A team can manage destinations and connections where the team has the Manage Destination or Manage Connection role, respectively. This includes assigning roles in the relevant resource to users and teams.

IMPORTANT: We recommend using teams when you want to ensure that only the relevant users or groups of users have access to the relevant destinations, connections or account settings. We recommend using organizations when you need to use separate security settings - SAML or SCIM.