Permissions

Metabase provides a comprehensive permissions system to ensure people only see the data they’re authorized to access. Permissions control both what data groups can view and what actions they can perform.

​

Key principles

Understanding these core concepts is essential for managing permissions effectively:

Permissions are granted to groups, not individuals

You assign permissions to groups, then add people to those groups. This makes permission management scalable and maintainable.Exception: User attributes can apply person-specific filters for row and column security.

Users can belong to multiple groups

A person can be a member of multiple groups simultaneously. Their effective permissions will be the most permissive across all groups.

Most permissive access wins

If a user is in three groups, and any one group has Curate access to a collection, that user gets Curate access—even if the other groups have No access.

Block All Users group first

Everyone belongs to the All Users group by default. Before granting specific permissions, block this group’s access to prevent unintended data exposure.Metabase will warn you if All Users has more permissive access than the group you’re restricting.

​

Accessing permissions settings

​

Permission types

​

Data permissions

Control access to databases, schemas, and tables.

​

View data permissions

Determines what data people can see in questions, dashboards, models, and metrics. Permission levels:

Can view data permission

Can view grants unrestricted access to all data in the source. Users can:

• View questions and dashboards using that data
• See models and metrics built on that data
• Need additional “Create queries” permission to browse databases

Granular view data permission

Granular lets you set different permissions for individual schemas or tables within a database or schema.Available only at database and schema levels. When selected, Metabase prompts you to set permissions for each child element.

Row and column security

Row and column security (formerly “sandboxing”) restricts data based on user attributes.Common use cases:

• Multi-tenant analytics: Each customer sees only their data
• Regional restrictions: Users see only their region’s data
• Role-based filtering: Managers see their team’s data only

Requires:

• User attributes configured for each person
• Table-level permission configuration

Can implement:

• Row filtering by column values
• Column hiding
• Custom SQL views of tables

Impersonated view data permission

Impersonated delegates permissions to your database’s role system.Benefits:

• Centralize permission management in your database
• Leverage existing database security policies
• Simplify permission administration

Metabase uses database roles to determine what each user can access. Only available at the database level.

Blocked view data permission

Blocked prevents all access to the data source.Important behaviors:

• Users cannot view questions using that data, regardless of collection permissions
• Blocks all native SQL queries from the entire database (even if only one table is blocked)
• Other groups with Can view access can override the block

​

Create queries permissions

Controls whether users can create new questions and use the database browser. Permission levels:

Query builder and native

Users can create questions using both:

• Metabase’s visual query builder
• Native SQL/NoSQL editor

If any table in a database has “Blocked” or “Row and column security” permissions, native query access is disabled for the entire database. Metabase cannot parse SQL to verify table access.

Query builder only

Users can:

• Create questions with the visual query builder
• Drill through existing questions
• Cannot write native SQL queries

Useful for users who need to explore data without SQL access.

Granular

Set different query permissions for individual schemas or tables.Allows fine-grained control over which parts of your database users can query.

​

Download results permissions

Control whether users can export query results and set row limits. Options:

• No: Cannot download results
• Granular: Set per-table or per-schema limits
• 10 thousand rows: Can download up to 10,000 rows
• 1 million rows: Can download up to 1 million rows

​

Manage table metadata permissions

Controls who can edit table and field metadata, including:

• Descriptions
• Display names
• Field types
• Visibility settings

Options:

• Yes: Can edit all metadata for the data source
• No: Cannot edit any metadata
• Granular: Set per-table permissions

​

Manage database permissions

Grants access to database connection settings. Users with this permission can:

• Edit connection options
• Sync schemas manually
• Scan field values
• View database settings page

​

Transform permissions

Controls access to manage and run transforms. Requirements:

• Can only be set at database level
• Requires “Can view” and “Query builder and native” permissions for all tables

​

Collection permissions

Control access to questions, dashboards, models, metrics, and other content. Permission levels:

​

Application permissions

Grant access to administrative features without making users full administrators.

Settings access

Control access to Admin > Settings tab, including:

• General settings
• Email configuration
• Slack integration
• Webhooks
• Maps
• Localization
• Appearance
• Public sharing
• Embedding
• Caching

Monitoring access

Grant access to:

• Performance tools
• Query logs
• Troubleshooting utilities
• Usage analytics

Subscriptions and alerts

Control who can create:

• Dashboard subscriptions
• Question alerts

Set to “No” to prevent users from creating new subscriptions and alerts.

​

Row and column security

Restrict access to specific rows and columns based on user attributes.

​

How it works

Row and column security creates a filtered version of a table that replaces the original table everywhere in Metabase for specific groups.

​

Types of security

Row-level security

Filter rows based on a single column matching a user attribute.Example: Filter Accounts table where Region column equals user’s region attribute.Users with region: "EMEA" see only EMEA rows. Users with region: "Americas" see only Americas rows.

Custom row and column security

Use a saved SQL question to define a custom view with:

• Multiple row filters
• Hidden columns
• Edited/transformed columns

Example: Create a “Restricted Accounts” question that:

• Hides the Email column
• Filters by multiple conditions
• Shows only specific date ranges

​

Setting up row and column security

​

Multi-tenant analytics tools

​

Database routing

Build questions once and route queries to different databases based on the user. Use case: Each customer has their own database with identical schemas.

​

Connection impersonation

Use database roles to manage permissions directly in your database. Use case: You prefer centralized permission management at the database level.

​

Best practices

​

Common permission patterns

Executive dashboard access

Scenario: Executives need view-only access to key dashboardsSetup:

• Create “Executives” group
• Grant “Can view” data permissions
• Grant “View” collection permissions to Executive Dashboards collection
• Block “Create queries” to prevent ad-hoc analysis

Data analyst full access

Scenario: Analysts need to explore and create contentSetup:

• Create “Analysts” group (or use Data Analysts group on Pro/Enterprise)
• Grant “Can view” data permissions
• Grant “Query builder and native” create permissions
• Grant “Curate” collection permissions
• Grant “1 million rows” download permissions

Regional sales teams

Scenario: Sales reps see only their region’s dataSetup:

• Add region user attribute to each rep
• Create “Sales” group
• Configure row-level security filtering Sales data by region
• Grant “Query builder only” create permissions
• Grant “View” collection permissions to Sales collection

Multi-tenant customer portals

Scenario: Each customer sees only their own dataSetup:

• Add customer_id user attribute
• Create per-customer groups or use single group with attributes
• Configure row and column security filtering by customer_id
• Grant “View” collection permissions to shared dashboards
• Block “Create queries” to prevent custom analysis

​

Troubleshooting permissions

User can't see expected data

Check:

1. User’s group memberships
2. All Users group permissions (might be blocking)
3. Both data and collection permissions
4. Whether data permissions are “Blocked” somewhere
5. Row and column security filters

User has more access than expected

Check:

1. All groups the user belongs to
2. All Users group permissions (most permissive wins)
3. Whether user is in Administrators group
4. Collection inheritance from parent collections

Native SQL disabled unexpectedly

Cause: Any table in the database has “Blocked” or “Row and column security” permissions.Solution: Remove row restrictions or use impersonation instead if users need SQL access.

Permission conflicts with row and column security

Cause: User is in multiple groups with different row and column security on the same table.Solution: Remove user from all but one group, or set other groups’ permissions to “Blocked” for that table.

​

Related documentation

• Users and groups management
• Authentication and SSO
• Row and column security examples
• Permissions strategies
• Troubleshooting permissions