This page covers permissions for databases and tables. If you haven’t already, check out our Permissions overview.
Now that you have some groups, you’ll want to control their data access by going to Admin settings > Permissions. You’ll see an interactive table that displays all of your databases and all of your groups, and the level of access your groups have for each database.
You can set various levels of permissions on a data source, from querying access to managing the database connection.
* Available on paid plans.
You can click on any cell in the permissions table to change a group’s access level. When you’re done making your changes, just click the Save changes button in the top-right, and you’ll see a confirmation dialog summarizing the changes.
Members of the group can access data from all tables (within all namespaces/schemas, if your database uses those), including any tables that might get added to this database in the future.
Granular access allows administrators to explicitly set access to tables or schemas within a database. In practice, this means that:
No self-service prevents people in a group from creating new ad hoc queries or questions based on this data, or from seeing this data in the Browse Data screen. Groups with this level of access can still see saved questions and charts based on this data in Collections they have access to.
⚠️
Block access
This feature is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud).
Block ensures people can’t ever see the data from this database, regardless of their permissions at the Collection level. So if they want to see a question in a collection that have access to, but that question uses data from a database that’s been blocked for that person’s group, then they won’t be able to see that question.
Keep in mind people can be in multiple groups. If a person belongs to another group that does have access to that database, that more privileged access will take precedence (overruling the block), and they’ll be able to view that question.
When you select Granular access for a database, you’ll be prompted to set permissions on the tables (or schemas) within that database. Here you’ll have two or three options, depending on your Metabase plan.
Groups with unrestricted access can ask questions about this table and see saved questions and dashboard cards that use the table.
Groups with no self-service access to a table can’t access the table at all. They can, however, view questions that use data from that table, provided the group has access to the question’s collection.
⚠️
Data sandboxing
This feature is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud).
Sandboxed access to a table can restrict access to columns and rows of a table. Check out data sandboxing.
Members of a group with Native query editing set to Yes can write new SQL/native queries using the native query editor. This access level requires the group to additionally have Unrestricted data access for the database in question, since SQL queries can circumvent table-level permissions.
People who aren’t in groups with Native query editing permissions will still be able to view the results of questions created from SQL/native queries, but not the code itself. They also won’t see the View the SQL button in the query builder.
⚠️
Download permissions
This feature is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud).
You can set permissions on whether people in a group can download results (and how many rows) from a data source. Options are:
⚠️
Data model permissions
This feature is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud).
You can define whether a group can edit metadata. Options are:
⚠️
Database management permissions
This feature is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud).
This setting defines whether a person can edit the connection settings for the data source, as well as to sync and scan the database. Note that this setting still prevents people from deleting database connections entirely. Only admins can delete database connections in your Metabase.
