Using Metabase to set up user level permissions for data security

If you’re rolling out dashboards and reports to a bunch of people, keeping sensitive data locked down isn’t optional—it’s table stakes. Maybe you’re a data analyst, admin, or just the unlucky soul who got handed “make sure people see only what they should” as a task. This guide cuts through the vague documentation and tells you exactly how to use Metabase to set up user-level permissions that actually work—and which settings aren’t worth your time.

Why Permissions Matter (And Where Metabase Fits In)

Metabase is popular because it’s easy to use and open source, but out of the box, its permissions system is pretty basic. If you’re running anything beyond a small team or have data you can’t let everyone see, you’ll need to spend time on permissions. Otherwise, mistakes are just waiting to happen.

What you can do with Metabase:

  • Restrict access to databases, tables, and even specific columns
  • Control who sees what dashboards or collections
  • Set up groups for different roles or departments

What you can’t do (at least easily):

  • Row-level security (showing different records to different users) unless you’re on the Enterprise plan or hack around it
  • Automatic sync with your company’s identity provider unless you set up SSO

If you’re expecting the granularity of enterprise BI tools, you’ll find Metabase is more “good enough” than “bulletproof.” But for most small to medium teams, it’s a solid start.

Step 1: Get Clear on Who Needs What

Don’t jump into the admin panel yet. First, make a simple list:

  • Who needs to see sensitive data?
  • Who just needs summary numbers?
  • Are there contractors or external folks?
  • Any regulatory requirements (GDPR, HIPAA, etc.)?

Map this to roles or groups. If you skip this, you’ll end up with a mess of one-off permissions that are impossible to audit.

Pro tip: If you can’t explain your groups to a non-technical manager in one sentence, you’ve overcomplicated things.

Step 2: Create User Groups in Metabase

Metabase permissions work through groups. Everyone starts in the “All Users” group (can’t delete or rename this—don’t bother trying). Best practice is to never assign real permissions to “All Users,” just use it as a baseline.

How to create groups:

  1. Go to Admin Panel (click your avatar in the bottom left > Admin).
  2. Click People > Groups.
  3. Hit Create a Group, name it something clear (e.g., “Finance,” “Sales—Read Only,” “External Contractors”).

You can nest groups for more complex setups, but honestly, most teams don’t need this. Keep it simple.

Add users to groups as needed. You can do this manually or, if you have SSO/LDAP, map groups there.

Step 3: Set Database and Table Permissions

This is where most people get tripped up. Permissions cascade from databases down to tables and columns.

How to set permissions:

  1. Still in Admin Panel, go to Permissions > Data.
  2. You’ll see a matrix: groups on the left, databases/tables on top.
  3. For each group, set their access:
    • No access: They can’t see it at all.
    • Unrestricted: Full access to query, join, and export.
    • Curate: Can create dashboards but not raw SQL queries.
    • SQL Only: Can write SQL queries but not use the GUI.

You can drill down by clicking on a database to set table-level permissions, and further to columns.

Pro tip: If you want to hide sensitive columns (like salary or SSNs), set those columns to “No access” for all groups except the few who need it.

Step 4: Control Access to Dashboards and Collections

Data isn’t just in tables—it’s in dashboards, too. Metabase organizes these into “collections.”

To set collection permissions:

  1. In Admin Panel, go to Permissions > Collections.
  2. Set each group’s access to each collection:
    • View: Can see dashboards/reports but not edit.
    • Curate: Can create and edit dashboards.
    • No access: Can’t see the collection at all.

Be careful: if someone can see a dashboard but doesn’t have access to the underlying data, some tiles might show errors or blanks. Always test permissions with a dummy user account.

Step 5: Handling Row-Level Security (If You Really Need It)

Here’s the honest bit: Metabase’s open source and Pro versions don’t have real row-level security. You can’t natively show “only records where sales_rep = current_user” unless you’re on Enterprise or get clever.

What are your options?

  • Enterprise version: Has “Data Sandboxing,” which lets you filter rows per user or group. If this is a dealbreaker, get a quote.
  • Database views: Create SQL views in your database for each group, then restrict access to those. Messy, but works.
  • Parameter filters: Some folks try to fake it by adding filters to dashboards, but this relies on user discipline—not security.

If you truly need row-level security and can’t pay for Enterprise, you’ll have to do it in the database. No way around it.

Step 6: Use Auditing and Test Your Setup

Trust, but verify. Metabase keeps logs of logins and queries, but it’s not a full-featured audit system.

  • Download audit logs from Admin Panel > Audit (if available).
  • Regularly test user accounts with minimal permissions. See what they can actually do.
  • If something sensitive leaks, fix your groups and permissions—not just the one dashboard.

Pro tip: Save a screenshot of your permissions matrix once in a while. When someone asks, “Who could see that?” you’ll have proof.

What to Ignore (or Not Overthink)

  • Granular per-user permissions: Always use groups, not one-off user settings. Otherwise, you’ll go insane tracking exceptions.
  • Complex group nesting: Unless you’re a huge org, simple is better.
  • Trying to bolt on row-level security without support: Don’t. It’s a headache and not secure.
  • Default permissions: Always review these after an upgrade—Metabase sometimes changes behaviors between versions.

Quick Real-World Gotchas

  • SSO group sync is flaky: Test after setup—sometimes users land in the wrong group.
  • Exports bypass some restrictions: Users with SQL access can sometimes export more than you’d expect. Check export permissions.
  • Collections can leak info: If you link to dashboards in Slack or email, double-check who has access before sharing.

Keep It Simple, Review Often

Don’t let your permission system become a black box. Start with broad groups, err on the side of less access, and add permissions only when someone needs them. Review your setup every quarter—especially after staff changes.

If you’re not sure about a setting, try it with a test user. Most security screw-ups happen because “it looked OK in the admin panel.” When in doubt, keep things locked down. You can always open the door later.

Now get back to work—your data is safer for it.