Metabase Permissions Guide: Data, Collections & Groups Setup

Metabase permissions control who can access databases, run queries, and view saved questions and dashboards. The system splits into two types: data permissions (which databases users can query) and collection permissions (which saved questions and dashboards users can see and edit). Getting this right prevents unauthorized access while enabling self-service analytics across your team.

What Are Metabase Permissions? (Data vs. Collection Explained)

Metabase permissions are divided into two categories: data permissions control database and table access, while collection permissions control access to saved questions and dashboards. Data permissions filter what data users can query; collection permissions filter what finished analysis users can see. Both types work together to create a complete access control model.

Data permissions are the foundation. They determine which databases, schemas, and individual tables a user can access when writing queries or browsing available data. If you want to restrict a user to marketing data only, you set data permissions on the marketing database or specific marketing tables. Data permissions operate at three levels: database level (all tables in a database), schema level (all tables in a schema), and table level (individual tables). This hierarchy lets you grant broad or granular access depending on your needs.

Collection permissions control access to the finished output: saved questions, dashboards, models, and the collections that organize them. Collections are folders that group related analysis. If you create a "Finance Reports" collection and place dashboards inside it, collection permissions determine who can view, edit, or delete items in that collection. This separation is powerful: you might let analysts query raw data (data permissions) but only let managers see the polished dashboard (collection permissions). Collection permissions take precedence over data permissions. A user with full database access but no collection permission cannot see questions in a restricted collection, even if the query would succeed.

Understanding this split prevents the most common permission mistake: granting data access but forgetting collection access, leaving users unable to see saved analysis even though they can query the data themselves. Many permission errors arise from this confusion, especially during initial setup.

How to Set Up Metabase Groups

Groups in Metabase let you apply permissions to multiple users at once. Instead of setting permissions for each person individually, you create groups like "Analysts" or "Sales Team", add users to them, and apply permissions to the group. This scales your permissions as your team grows.

To create a group, go to Admin Settings > People > Groups, then click "Create a new group". Give it a descriptive name: use role-based names like "Sales Analysts", "Marketing Team", or "Finance Admins" rather than individual names. Add users to the group by clicking the group and selecting users. You can add and remove users at any time.

Once the group is created, apply data and collection permissions to it. Any user in the group inherits all permissions assigned to that group. If you move a user to a different group, their permissions update immediately. This is much simpler than managing permissions for 50 individual users. A typical small team structure has four to five groups: Admins (all access), Power Users (broad query and edit access), Viewers (read-only dashboards), and sometimes a Restricted Access group for external partners or contractors. As your team grows, you can add specialized groups for departments.

Setting Up Data Permissions: Who Sees Which Databases?

Data permissions control which databases and tables each group can access. You set permissions at three levels: database level, schema level, and table level. For each level, you choose an access type like "Query builder only", "Query builder and native query", or "Unrestricted". Users can then query data they have access to.

To set data permissions, go to Admin Settings > Permissions > Database Permissions. Select the group, then choose each database. For each database, you select the permission level:

• No access: The database does not appear in the data browser or query builder. The user cannot see it at all.
• Query builder only: The user can write visual queries in the query builder but cannot write SQL (native queries). This is ideal for non-technical users who need to explore data without access to raw SQL, which can be used to bypass restrictions.
• Query builder and native query: The user can write both visual queries and SQL. Useful for analysts who need flexibility.
• Unrestricted: Full access to the database, including all schemas and tables.

If you want more granular control, you can set permissions at the schema or table level instead of database level. For example, you might give a group "Query builder only" access to the production database at the database level, then override specific sensitive tables (like user passwords or financial data) to "No access". This prevents anyone in the group from querying those tables, even though they have database access.

Native SQL queries are a special consideration. If you set data permission to "Query builder only", users cannot write SQL queries directly; they can only use the visual query builder. This is useful if you want to restrict access to sensitive raw SQL, which could be used to extract data that visual restrictions would prevent. However, it means those users cannot create or run complex queries that require SQL. Many teams use this for read-only business users and reserve SQL access for analysts.

Setting Up Collection Permissions: Controlling Questions and Dashboards

Collection permissions control who can view, edit, and organize saved questions, dashboards, and models. Collections are folders that hold your saved analysis. You assign "Curate" (edit and delete), "View" (read-only), or "No access" permissions to each collection per group. Collection permissions override data permissions: a user with data access but no collection permission cannot see saved questions in that collection.

Collections are typically organized by team, business function, or project. A dashboard team might have collections like "Sales Dashboards", "Finance Reports", "Product Metrics", and "Internal Tools". Each collection contains related questions, dashboards, and other cards. By organizing collections this way, you can assign permissions per collection rather than per-item, making it easier to manage access as your collections grow.

View permission lets users see and run questions, dashboards, and models in the collection, but not edit them. They cannot modify the query, rename the question, or move it. This is appropriate for business users consuming dashboards or reports. Curate permission lets users do everything: create, edit, delete, and reorganize items in the collection. Use this for analysts or teams that own the analysis. No access hides the collection entirely; the user does not see it in the navigation or search.

Collections can be nested, meaning a collection can contain sub-collections. The permission hierarchy follows nesting: if a user has View access to a parent collection, they see and can run items in that collection and its sub-collections. However, you can restrict a sub-collection to a tighter permission level; for example, a user might have Curate access to the "Sales" collection but only View access to the "Sales - Finance Review" sub-collection. This flexibility helps organize access as complexity grows.

An important detail: collection permissions and data permissions work together but are independent. A user might have View access to a collection but no data permission on the underlying database. In this case, if they open a question that queries that database, they see a "permission denied" error. Conversely, a user might have data permission to query a database but only View permission to the collection, meaning they can query the data in the query builder but cannot see saved questions about that data. Always ensure both data and collection permissions are set appropriately.

A Safe Default Setup for Your 10-Person Team

A practical starting point for a 10-person team is four core groups: Admins (all access), Analysts (unrestricted query and curate their own collections), Managers (view reports and limited queries), Viewers (view-only access). Assign data permissions by role: Analysts get full database access, Managers get summary tables only, Viewers get one restricted collection per manager. This template is not a strict rule, but it provides a sane baseline that prevents over-sharing and under-sharing.

Here is a concrete example. Your company has 10 people: you (founder), two finance people, two sales people, two marketing people, two product managers, and one developer. Create four groups:

1. Admins: You and the developer. These two have all access to all databases and all collections. They can see everything and change any permission.

2. Analysts: Your finance and marketing people. These four have Unrestricted access to all databases (they can write SQL and query anything). Each analyst manages one collection for their function (for example, "Finance Reports" and "Marketing Dashboards"). Other functions' collections are set to No access. This prevents accidental edits and keeps dashboards organized.

3. Managers: Your sales and product leads. These two have Query builder only access to a restricted set of tables: summary tables, revenue tables, and customer tables, but not raw transaction details or cost data. They have View access to one collection each (for example, "Sales Summary" and "Product Metrics"). They can see and run dashboards but cannot edit or create new ones.

4. Viewers: Invite contractors, partners, or team members who need to see only one dashboard. These people have No access to all databases (they cannot query data directly). They have View access to one collection only, perhaps "Public Dashboards". This prevents them from exploring data or discovering sensitive tables.

Implement this by creating each group, adding users, then setting permissions:

1. Go to Admin Settings > People > Groups.
2. Create "Admins", "Analysts", "Managers", "Viewers".
3. Go to Admin Settings > Permissions > Database Permissions.
4. For "Analysts": Set all databases to Unrestricted.
5. For "Managers": Set marketing and sales tables to Query builder only, hide finance and cost tables (No access).
6. For "Viewers": Set all databases to No access.
7. Go to Admin Settings > Permissions > Collection Permissions.
8. Create collections by function (Finance, Marketing, Sales, Product).
9. Set collection permissions: Analysts have Curate on their function's collection, View on others. Managers have View on their collection only. Viewers have View on the one shared collection.

As you hire a third finance person, add them to the Analysts group. Permissions apply immediately. If a contractor leaves, remove them from their group, and their access disappears. This structure scales to about 30 people before you need to refine it further (for example, splitting Analysts into senior and junior analysts with different SQL access, or breaking collections into smaller sub-collections per team).

Advanced: Row-Level Security and Sandboxing

Row-level security (RLS) and column-level security (CLS) filter data dynamically based on user attributes. RLS restricts which rows a user sees (for example, sales reps see their own territory), while CLS hides sensitive columns (for example, salary data). These features are available in Metabase and use user metadata to filter results automatically. Opsily's hosted Metabase can run any Metabase edition, including those with RLS and CLS capabilities.

RLS is useful when multiple teams query the same database but should see different subsets of data. For example, a sales company has one customers table. Sales reps in the US region should see only US customers, and sales reps in Europe should see only European customers. Without RLS, you must create separate databases or views per region, which is complex. With RLS, you create one table and define a rule: "If the user's region attribute is 'US', filter the customers table to region = 'US'." Metabase applies this filter automatically every time the user queries that table, so they only see their region's data.

CLS works similarly but at the column level. You might have an employees table with a "salary" column. Everyone should see employee names and departments, but only managers should see salaries. Define a rule: "If the user's role is not 'manager', hide the salary column." Metabase removes the column from the result set for non-managers.

RLS and CLS require Metabase editions that support these features (not available in the open-source version). The exact edition list changes, so check metabase.com/pricing for current support. If you are using self-hosted Metabase, you need to have the right license to use these features. The implementation requires setting up user attributes (metadata fields on each user like region, team, or salary_visibility) and then defining filters in Metabase. This is an advanced setup and beyond the scope of this guide, but it is powerful for multi-tenant or multi-region deployments.

Common Permission Mistakes and Troubleshooting

Three common errors plague Metabase permission setups: (1) Users see "You do not have permission" errors because collection permissions are not set, even though they have data access. (2) Native SQL queries fail because data permission is set to "Query builder only". (3) Permissions appear to change randomly because group membership changed but the user was not informed. Always verify collection permissions first when debugging access issues.

Error: User sees "You do not have permission to run this query"

This is almost always a collection permission issue, not a data permission issue. The user has data access but no collection permission. Check Admin Settings > Permissions > Collection Permissions. Make sure the user's group has "View" or "Curate" access to the collection containing the question. If the question is in the Personal collection (the default for new questions), the user needs View access to that collection. Many teams forget to set personal collection permissions. Fix it by assigning the user's group View access to the collection.

Error: User tries to run a SQL query and gets a permission error

The group's data permission is set to "Query builder only", which disables SQL access. Go to Admin Settings > Permissions > Database Permissions, find the database, and check the group's permission. If it is "Query builder only", change it to "Query builder and native query". Alternatively, if the user should not have SQL access, this error is correct behavior and not a mistake.

Problem: A user's permissions seem to change after an upgrade or admin change

Metabase 50 introduced changes to the permission model. If you recently upgraded, permissions may have been recalculated. Check the release notes. Additionally, if an admin moved a user to a different group or changed group permissions, the user's access changes immediately but they may not realize it. Send a notification to affected users when you change permissions.

Debugging checklist:

1. Verify the user's group. Go to Admin Settings > People, click the user, check their group membership.
2. Verify the group's data permission. Go to Admin Settings > Permissions > Database Permissions, find the database and group, check the permission level.
3. Verify the group's collection permission. Go to Admin Settings > Permissions > Collection Permissions, find the collection and group, check the permission level. Ensure the group has at least "View" access.
4. Test with a different user in the same group. If that user also has no access, the issue is group permissions. If the other user has access, the issue is specific to the first user's configuration.
5. Check the browser console for error messages. Metabase sometimes logs permission-related errors there.

Frequently Asked Questions

What's the difference between data permissions and collection permissions in Metabase?

Data permissions control which databases and tables a user can query. Collection permissions control which saved questions and dashboards a user can view and edit. A user needs both: data access to query a database, and collection access to see a dashboard that uses that data. Collection permissions override data permissions.

How do I set up groups in Metabase?

Go to Admin Settings > People > Groups, click "Create a new group", give it a name, and add users. Then go to Admin Settings > Permissions > Database Permissions and Collection Permissions, select the group, and assign permissions for each database and collection.

Can I restrict users to specific rows or columns?

Yes, via row-level security (RLS) and column-level security (CLS). These filter data based on user attributes automatically. RLS restricts rows, CLS restricts columns. These are advanced features available in certain Metabase editions. Check metabase.com/pricing for current support and limitations.

What happens if a user has data access but no collection permission?

They cannot see the saved question or dashboard. If they try to run a query that references that database, they get a "permission denied" error. They can write their own queries in the query builder (using their data access) but cannot view saved analysis in restricted collections.

How do I prevent a user from writing SQL queries?

Set the group's data permission to "Query builder only" for the database. Users in that group can write visual queries but cannot write SQL (native queries). This is useful for non-technical users who should explore data without direct SQL access.

What's the difference between "Curate" and "View" in collection permissions?

View permission lets users see and run items in the collection but not edit them. Curate permission lets users create, edit, delete, and reorganize items. Use View for consumers of dashboards and Curate for teams that create and own analysis.

The Bottom Line

Metabase permissions split into data permissions (database and table access) and collection permissions (question and dashboard access). Use groups to manage permissions at scale. Data and collection permissions work together: a user needs both to fully access saved analysis. Create a practical starting point with four groups (Admins, Analysts, Managers, Viewers) and assign permissions by role. Row-level and column-level security are available for advanced filtering. Most permission errors stem from missing collection permissions, not data permissions. If you are setting up Metabase for your team and want to skip the permission configuration complexity, Opsily's managed Metabase hosting handles permissions, backups, and security out of the box.