There are always going to be sensitive bits of information in your databases and tables, and thankfully Metabase provides a simple way to ensure that people on your team only see the data they’re supposed to.
Metabase uses a group-based approach to set permissions and restrictions on your databases and tables. At a high level, to set up permissions in your Metabase instance you’ll need to create one or more groups, add members to those groups, and then choose what level of database and SQL access those groups should have.
A user can be a member of multiple groups, and if one of the groups they’re in has access to a particular database or table, but another group they’re a member of does not, then they will have access to that database.
In addition to setting permissions on your databases and tables, you can also set access permissions on the collections where your dashboards, questions, and pulses are saved. Collection permissions are not set from the Admin section; set them by clicking on the edit/pencil icon in the top-right of the screen when viewing a collection.
To view and manage your groups, go to the Admin Panel, click on the People section, and then click on Groups from the side menu.
You’ll notice that you already have two default groups: Administrators and All Users. These are special groups that can’t be removed.
You’ll also see that you’re a member of the Administrators group — that’s why you were able to go to the Admin Panel in the first place. So, to make someone an admin of Metabase you just need to add them to this group. Metabase admins can log into the Admin Panel and make changes there, and they always have unrestricted access to all data that you have in your Metabase instance. So be careful who you add to the Administrator group!
The All Users group is another special one. Every Metabase user is always a member of this group, though they can also be a member of as many other groups as you want. We recommend using the All Users group as a way to set default access levels for new Metabase users. If you have Google single sign-on enabled, new users who join that way will be automatically added to the All Users group.
As we mentioned above, a user is given the most permissive setting she has for a given database/schema/table across all groups she is in. Because of that, it is important that your All Users group should never have greater access for an item than a group for which you’re trying to restrict access — otherwise the more permissive setting will win out. This goes for both data access as well as collection permission settings.
If you’ve set up the Slack integration and enabled Metabot, you’ll also see a special Metabot group, which will allow you to restrict which questions your users will be able to access in Slack via Metabot.
From the Groups section, click the
Add a group button to create a new group. We recommend creating groups that correspond to the teams your company or organization has, such as Human Resources, Engineering, Finance, etc. Click the X icon to the right of a group in the list to remove it (remember, you can’t remove the special default groups). By default, newly created groups don’t have access to anything.
Click into a group and then click
Add members to add users to that group. Click on the X on the right side of a group member to remove them from that group. You can also add and remove users from groups from the People list using the dropdown in the Groups column.
Now that you have some groups, you’ll want to control their data access by going to the
Permissions section of the Admin Panel. 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 click on any cell in the 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.
At the database level, there are two different kinds of access you can set: data access, and SQL (or native query) access.
If you select
Limit access for one of your databases, your view will change to show the contents of that database. If the database utilizes namespaces or schemas, you’ll see a list of all the schemas in the database, and the level of data access each group has for them. Similarly, if you select
Limit access on one of your schemas, you’ll drill down a level and see all the tables within it. From these views, you can navigate back by using the breadcrumb links in the top-left, and you can always drill down into a database or schema using the link under its name in the left column.
Data access levels for schemas follows the same pattern as for databases:
Lastly, data access levels for tables are almost exactly the same as well:
Note: you’ll notice that tables don’t have the option for limited access. In the future, column-level permissions will be added to Metabase, and setting limited access on a table will allow you to choose which columns the group should have access to.
Pulses act a bit differently with regard to permissions. When a user creates a new Pulse, they will only have the option to include saved questions that they have permission to view. Note, however, that they are not prevented from emailing that Pulse to anyone, or posting that Pulse to a Slack channel (if you have Slack integration set up), regardless of the recipients’ permissions. Unlike dashboards, where individual cards are blocked based on a user’s permissions, a Pulse will always render all of its cards.
Learn how to create collections of dashboards, questions, and pulses to organize things and decide who gets to see what in the next section.