What Metabase row and column security does for each group
Teams often need one shared Metabase instance where each sales region, business unit or customer sees only its own records. Row and column security, formerly called data sandboxing, is the Metabase feature built for that case. It filters what a group can view and query based on user attributes, so the same dashboards and saved questions can serve several groups without exposing the others' data. It is a Pro and Enterprise feature, and it is available whether you self-host Metabase or use Metabase Cloud.
The feature matters most when separate instances would create more work than they remove. Running one Metabase per region or per customer duplicates dashboards, permissions, upgrades, backups and the application database, and each copy drifts over time. Database-only controls, such as giving each group its own database user with native row-level security, protect the data but do not scope what people see inside Metabase itself. If your groups share content and infrastructure but must not share rows, row and column security is usually the better fit. If the data itself must be physically isolated for contractual or regulatory reasons, separate instances or separate databases may still be required.
Before you commit to this design, confirm the attribute model with the people who own the data. Each user needs an attribute, such as a region code or customer identifier, that maps cleanly to a column in the source table. Ask who maintains those attributes when someone changes teams, and whether they come from your identity provider. Attribute sync from directories and SCIM provisioning are gated to Pro or Enterprise in the Metabase people and groups documentation, so confirm which plan your identity setup requires before you design around it.
Next, map each table and group combination to a policy. Metabase allows one policy per table and group, so a group with access to several tables needs a decision for each one. A basic row policy filters on a single column. A custom policy, built from a saved SQL question, can filter on several columns and can also restrict or edit which columns a group sees. Column restriction is where many designs need the most review, because hiding a column in one question does not hide it from every path to the data. Ask for a list of sensitive columns per table and test each group against it.
Finally, plan verification and change control. Test each policy by signing in as a representative user from each group and checking both dashboard views and ad hoc questions, including questions built in the query builder and in SQL. Record which group owns each policy, who approves a change, and how a policy is reviewed after a reorganization. Confirm the current plan terms on Metabase's pricing page before purchase, since feature availability is tied to the plan and may change.
Basic row policies versus custom SQL policies
This table compares the two policy types Metabase row and column security offers, so you can match each group's access rule to the simpler or more flexible option. Read each row as a decision point, and use the final rows to judge when a basic policy should move to a custom one. Both types apply one policy per table and group combination, so plan your rules around that limit.
| Aspect | Basic row policy | Custom SQL policy |
|---|---|---|
| Data shape it fits | A table where one column, such as region, business unit or account owner, decides which rows a group can see | Data where access depends on several columns, or where a group must lose or change specific columns |
| Row filtering | Filters on a single column | Can filter on multiple columns through the saved question's logic |
| Column restriction | Not part of this policy type | Can restrict or edit the columns a group sees |
| How it is authored | Set in the admin interface by choosing a column and mapping it to a user attribute | Built from a saved SQL question that the policy uses as its source, so the author needs SQL skills |
| Maintenance and review | Low effort: reviewers check the column choice and attribute values | Higher effort: every SQL change needs review and retesting when source table columns change |
| Query performance | Adds a single filter condition, which is simple to reason about | Performance depends on the saved question's SQL, so test it against production-sized data |
| Plan requirement | Pro or Enterprise, self-hosted or on Metabase Cloud | Pro or Enterprise, self-hosted or on Metabase Cloud |
| When to move to custom | Move when a second column must affect access, when columns must be hidden, or when the single-column rule no longer fits the data | Stay on custom only while the logic needs it, since each change adds review work |
| Limits to confirm | One policy applies per table and group combination; confirm current limits and supported attribute types in the Metabase docs | The same one-policy-per-combination limit applies; confirm the current rules for saved question sources in the Metabase docs |
How row and column policies filter queries
Row and column security, formerly called data sandboxing, decides what a group can view and query based on attributes stored on each user. The model has four parts that apply in order. Each Metabase user carries attribute values, such as a region or business unit, set by an administrator or synced from an identity provider. Users belong to groups, and the group is the unit that receives permissions. A policy then binds one table to one group, so you can define at most one policy for each table and group combination. When a member of that group runs a question, Metabase applies the policy to the query, whether the question is saved or newly written.
- Attributes live on users: a policy refers to attribute names, so changing one user's value changes what that user sees without editing the policy.
- Groups carry access: add a user to a group to enable the policy for that group's tables.
- One policy per table and group: plan for a single rule set per pairing, and place every condition for that pairing inside it.
- Saved and new queries both filter: a dashboard built by one user does not bypass the policy for a viewer in the restricted group.
- Attribute sync is a paid feature: advanced attribute sync from an identity provider requires Pro or Enterprise, so confirm where attributes will originate.
Before building policies, write down the attributes, groups and table pairings on paper and confirm each one with the data owner. Check how an existing saved question behaves for a restricted user before you rely on the policy.
A row filter limits which records a group can read from a table. A basic row policy compares one column with a user attribute, so a user only sees rows whose column value matches their own attribute. This is the simplest form and suits cases like a regional sales table where each region maps to one attribute value. Because the filter runs for every query from that group, the restriction holds across dashboards, exploration and ad hoc questions in that table.
- Single column comparison: a basic policy filters on one column against one attribute.
- Consistent across entry points: the same row rule applies to the query builder and to saved questions.
- Attribute values must match the data: a mismatch in case, spelling or formatting returns no rows, which can look like a broken dashboard.
- Multiple conditions need a custom policy: when rows depend on more than one column, a basic policy is not enough.
- Test with real attribute combinations: create a test user for each group and attribute value and compare row counts with the source system.
Illustrative example: a user with a region attribute of "north" sees only rows where the region column equals "north" in the orders table. Confirm with your Metabase version and plan that the row filter behaves as your test cases expect before production use.
Column restriction is a separate concern from row filtering. It decides which fields a group can see or use, and a group can be restricted on columns even when it can see every row. Sensitive fields such as personal identifiers, salary or account numbers are typical candidates. Restricting columns protects the data itself rather than only narrowing which records appear, so a user cannot retrieve a hidden field through a summary, a filter or an export that references it.
- Decide column access per table and group: list which fields each group needs for its questions and dashboards.
- Review derived views: a summary of a restricted column can still reveal information, so check aggregations and filters too.
- Keep row and column rules distinct: document which control blocks which exposure so auditors can trace each decision.
- Check downstream content: dashboards, saved questions and pulse reports built by other users may reference fields the group cannot read.
- Confirm the column behavior in your version: the exact handling of restricted fields in each query type should be verified in a test instance.
Illustrative example: a finance group can read transaction amounts and dates but not the customer tax identifier column. Before granting access, run each dashboard as that group and confirm the hidden column does not appear in results, filters or exports.
A custom policy is based on a saved SQL question. Instead of comparing one column to one attribute, the saved question defines the data a group can read, so it can filter on several columns and can restrict or edit columns. The saved question acts as a controlled view of the table for that group. This approach fits rules that a basic policy cannot express, such as combining region and product line, or returning a masked version of a field. The trade-off is that the SQL becomes part of your access control and must be maintained alongside schema changes.
- Filter on several columns: combine conditions that a single-column policy cannot express.
- Restrict or edit columns: remove sensitive fields or transform them in the saved question.
- Treat the SQL as controlled code: review, version and test it like any other access rule.
- Watch for schema drift: renamed or dropped columns can break the policy or expose new fields, so monitor table changes.
- Confirm the database user: verify which database credentials run the saved question and what they can reach directly.
Illustrative example: a saved question returns only rows for a partner's accounts and omits internal cost columns. Test the saved question against a copy of the data, then confirm that the restricted group sees the same results through the policy and that no direct table path remains open.
Which Metabase plans include row and column security and what that means for cost
Row and column security is available only on the Pro and Enterprise plans, according to Metabase's pricing page. It is not included in Open Source or Starter. Metabase calls this feature row and column security, formerly data sandboxing, and it applies to self-hosted instances as well as Metabase Cloud. Because the plan determines whether the feature exists at all, the licensing decision comes before any policy design or build work. Confirm the current plan terms with Metabase before you commit to a design that depends on per-group row filters or custom SQL-based column restrictions.
The published Pro price is $575 per month, or $517.50 per month when billed yearly, with 10 users included. Each additional user costs $12 per month. For illustration only, a team of 25 users on Pro monthly would pay $575 plus 15 extra users at $12 each, which is $755 per month. Enterprise starts at $20,000 per year and is priced by quote. Both figures are recurring license costs, so they continue for as long as the instance runs. Ask any vendor or reseller for a written quote that states the user count, billing term, support scope and what happens when you add users mid-term.
Once the plan is chosen, the license is only one part of the spend. Your team or a partner still pays for the build: mapping user attributes to row filters, writing and testing saved SQL questions for column restrictions, and verifying that each group sees only its data. Those hours are one-time work, but policy changes after go-live recur as data models and teams change. Ask whether the license activation steps and any tiering changes are documented for your deployment model, and confirm them in your own environment before you plan the timeline.
Row and column security rarely arrives alone in a buyer's review. Single sign-on through JWT, OIDC or SAML, advanced LDAP group and attribute sync, and SCIM provisioning also require Pro or Enterprise, according to Metabase's people and groups documentation. Multi-tenant data segregation and usage analytics and auditing are Pro and Enterprise features as well. List every control your security and compliance teams need, mark each one as Pro or Enterprise, and total that list against the plan price. That total is the realistic basis for comparing a Pro deployment with an Enterprise quote.
Setting up row and column security on a Pro or Enterprise instance
This sequence takes a self-hosted Metabase instance from plan check to tested row and column restrictions, with a verification step after each stage so each group sees only the data it is permitted to see. It also shows where the application database and upgrade process affect the work.
Confirm plan, version and application database
Before any configuration, confirm that the instance runs a Pro or Enterprise plan, since row and column security is not available on Open Source or Starter. Record the exact Metabase version, and confirm the application database is PostgreSQL or MySQL rather than the embedded H2 database, which is intended for demos. Take a backup of the application database before making permission changes, because policy records live there and restoring it is the documented rollback path for upgrades. The step is complete when the plan, version and database type are written down and a backup exists that you have confirmed can be restored. Confirm the plan and feature availability with Metabase directly, because licensing can change.
Define groups and user attributes
Decide which groups need different data views, and which user attributes will drive filters, such as a region, business unit, or customer identifier. Each attribute must exist on the user record or come from your identity provider through the sync method your plan supports, so confirm with your team which source is authoritative. Create the groups in Metabase and assign test users to each one, including at least one user per group whose attribute values you control. The step is complete when every group has a documented purpose, every attribute has a named source, and the test users show the expected attribute values on their profiles.
Map table access for each group
For each group, decide which databases and tables it may view and query. Set data permissions at the database and table level first, so that a group without access to a table cannot reach it through either the query builder or SQL. Row and column policies are layered on top of these permissions, so mapping access first avoids policies that protect tables a group should not see at all. Record the mapping in a table that lists group, database, table and access level. The step is complete when a test user in each group can open only the tables on its list, and when a test user in a restricted group receives a permission error on a table outside that list.
Write and test basic row policies
Create basic row policies for each table and group combination that needs filtering. A basic policy filters on a single column and compares it with a user attribute, so start with the simplest policies that cover the most sensitive rows. Keep to one policy per table and group pair, as Metabase allows. Once saved, sign in as a test user in each affected group and open a saved question and an ad hoc query on the filtered table. Confirm that row counts match the expected subset for that user's attribute value, and that switching the test user's attribute changes the returned rows. The step is complete when each group's results match a known row count you have checked directly in the database.
Add custom SQL policies for column restriction
Where a group needs multiple-column filters or must not see certain columns, build a custom policy from a saved SQL question. These policies can filter on several columns and can restrict or edit columns, so write the saved question to return only the columns the group may see and to apply the required conditions. Because custom policies are more complex than basic ones, review the SQL with a database-literate team member before saving. Verify by signing in as each affected test user and confirming that restricted columns are absent from saved questions, dashboards and ad hoc queries, and that the filtered rows still match your direct database check. The step is complete when restricted columns cannot be seen or queried by the test users, including through SQL.
Run a full verification pass
Repeat the checks across every group and every affected table, including saved questions, dashboards, ad hoc queries and any SQL editor access. Test edge cases such as users with no attribute value, users in more than one group, and users whose attribute changes after sign-in. Record the results, with the expected and observed row and column counts for each test. Keep the test users and the expected results so you can rerun the pass after any change. The step is complete when every test in the pass matches its expected result, and the results are stored with the configuration record.
Plan for upgrades and version changes
Row and column policies live in the application database, so every Metabase upgrade runs migrations against that database. Before any upgrade, back up the application database, and if you run a cluster, plan to reduce it to a single node for major upgrades because of the migration lock. After the upgrade, repeat the verification pass, because permission behavior can change between versions. Confirm exact menu paths and setup screens against the current Metabase documentation for your version, since interface details change between releases. The step is complete when the upgrade runbook includes the backup, the verification pass and the rollback path, and when a restore has been tested in a non-production environment.
Using row and column security for multi-tenant data segregation
In a multi-tenant Metabase design, one instance serves several customers or business units, and row and column security is the mechanism that keeps each tenant's rows and columns out of the others' view. Each tenant is typically modeled as a group, and a row policy or a custom policy is defined for each table and group combination. Row and column security filters what a group can view and query based on user attributes, so the policy model carries the segregation logic. Before you adopt that design, confirm that it fits your data. Row and column security is available only on Pro and Enterprise plans, self-hosted or on Metabase Cloud, and the pricing page lists multi-tenant data segregation as a Pro and Enterprise feature. Confirm the current plan terms with Metabase before you budget for the design.
A basic row policy filters on a single column, which works when every tenant is identified by one value such as a tenant ID. A custom policy based on a saved SQL question can filter on several columns and can restrict or edit columns, which helps when tenant identity depends on more than one field or when some columns must be hidden from certain tenants. The point where the policy model stops being the right tool is when tenant rules become complex, when tenants need hard isolation for contractual or regulatory reasons, or when a single missed policy would expose another customer's data. In those cases, the trade-off is between shared tables filtered per tenant and separate schemas or databases per tenant. Shared tables are cheaper to operate and easier to change centrally, but every query depends on the filter being correct. Separate schemas or databases make the boundary structural, at the cost of more objects to provision, migrate and monitor.
Before a tenant onboards, test the policy against that tenant's real access pattern in a non-production instance. Create a test user in the tenant's group, open the saved questions and dashboards they will use, and confirm that every result set contains only that tenant's rows and the permitted columns. Test the query builder and any SQL questions separately, because a custom policy may behave differently for each. Also test the negative case: a user in a different tenant group should see none of the first tenant's data. Plan for the risk of a missed policy, which is the most serious failure in this design. A table without a policy for a given group may be visible in full to that group, so inventory every table and group combination, and document which combinations have no policy and why.
Group membership changes are the second main risk, because a user moved into the wrong group receives the wrong tenant's view without any error. Review group membership on a fixed schedule and after every onboarding, offboarding or role change. Require a named approver for each change to a tenant group, and keep a record of who changed which membership and when. If your identity provider manages group sync, confirm which group changes Metabase applies automatically and which are managed by hand, since the advanced group and attribute sync features require Pro or Enterprise. Ask Metabase and your own identity team to confirm how removals propagate, because a user removed upstream may keep access until the next sync or session expiry in your configuration.
Security risks in row and column policies and how to control them
Row and column security decides what each group can see, so a small configuration error can expose data without any visible failure. The risks below cluster around four places where policies are created, joined, populated and administered, and each one has a specific control that your team can check before go-live and again after every schema change.
Table left without a policy for a group
Row and column security applies one policy per table and group combination, so a table that has no policy for a group can remain fully visible to that group. Check each group against every sensitive table, not only the tables you planned for. Control this with least-privilege group design: start each group with no data access, then grant access table by table, and review the matrix of groups and tables before each release.
Custom SQL policy exposing columns through joins
A custom policy based on a saved SQL question can filter on several columns and restrict or edit columns, but a join can reintroduce a hidden field if the question pulls in a related table without the same restriction. Illustratively, a policy that hides a salary column on an employee table may still show it through a join to a payroll table. Test each custom policy as the affected group, and confirm every joined table carries its own policy for that group.
Attribute values set incorrectly at provisioning
Row filters depend on user attributes, so a wrong region, tenant or department value sent during provisioning gives a user rows that belong to someone else. The risk grows when attributes come from SSO or directory sync, where a mapping error can apply to many accounts at once. Confirm which identity provider attributes feed Metabase, test a sample of accounts with known values, and check that the attribute mapping is part of your change process.
Over-broad admin rights that can edit policies
Anyone who can edit permissions or policies can widen their own access or someone else's, which makes row and column rules only as strong as the admin group. Limit administrator rights to a small named set of people, separate the people who manage data sources from those who manage policies where your size allows, and review the admin list on a fixed schedule. Keep a record of who changed each policy so that unexpected edits can be traced.
Policy drift after schema changes
When a column is renamed, added or retyped in the source database, a policy written against the old structure may stop filtering as intended or may leave a new sensitive column open. Schema changes often happen outside the analytics team, so this risk is easy to miss. Add a review of row and column policies to every database change that touches a table used in Metabase, and rerun the group tests after each change.
Audit and usage evidence for access reviews
Usage analytics and auditing are included in the Pro and Enterprise plans, and they show who queried which data, which supports access reviews and incident investigation. Open Source and Starter do not include these capabilities, so confirm whether your control set requires them before choosing a plan. DeployOpen can prepare the configuration, test records and evidence you need, but independent auditors and certification bodies issue audit reports, not DeployOpen.
Keeping row and column policies intact through Metabase upgrades
Every Metabase upgrade should be treated as a possible change to your row and column security. Upgrades run application database migrations automatically, and the row and column policies you configure for each table and group are stored in that application database. A migration can therefore change how those policies are read without any visible change in the admin settings. After each upgrade, sign in as a test user from every sandboxed group and confirm that the rows returned and the columns shown or hidden still match the policy you designed. Keep a written list of those checks so the same tests run every time.
Metabase's upgrade documentation sets out the steps to follow before you start. First, back up the application database, so you have a restore point that predates the migration. Second, for major upgrades, reduce a clustered deployment to a single node, because the migration takes a lock that other nodes cannot work around during the change. Third, if your instance is on a release older than 40, upgrade one release at a time rather than jumping straight to the target version. Plan the window for each of these steps in your own environment, and confirm the exact sequence for your starting version against the upgrading documentation before you schedule the change.
Rollback needs a decision made in advance. Metabase documents two paths: restoring the pre-upgrade application database backup, which is the recommended option, or running the migrate down command with the newer JAR. The restore path returns the application database to the state it had before the migration, including the policy definitions. Test that restore in a non-production copy before you rely on it, then repeat the row and column checks against the restored instance. Ask your Metabase contact or check the upgrading documentation for any version-specific guidance before you choose the migrate down path, since it depends on the release involved.
Use the support window as the planning input for upgrade timing. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after about two months. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027, and Metabase 65 was released on 12 October 2026. Schedule upgrades so that you move to a supported LTS release with time to run the policy tests before the end-of-life date. Confirm the current end-of-life dates on the Metabase version support page when you plan, because those dates are set by the vendor and can change the schedule you chose.
Limits to confirm in your environment before you rely on this control
Row and column security decides what each group sees, but its reach depends on your database engine, how content is shared, and which plan you run. The cards below list the points to test on a Metabase instance that matches your production setup, against the current Metabase documentation.
Database engines and connection types
Confirm which database engines and connection methods support the row and column policy behavior you need, since support can differ by driver and version. Test each engine you plan to use with a policy filtering on one column and with a custom policy built on a saved SQL question. Record which connections enforce the policy and which do not, and keep that list with the control documentation.
Policies across saved questions and models
Check how a policy applies to saved questions, models, and dashboards built by users in a restricted group, and whether any content path returns rows the policy should hide. Build one test question, one model, and one dashboard tile for a restricted user, then compare the results with an unrestricted account. Note any content that a restricted user can create or edit outside the policy.
Embedded content and public links
Confirm how embedded dashboards and public links handle row and column restrictions, since they may run queries outside the signed-in user's group. Verify whether guest embedding applies the intended policy for each tenant or segment. Treat public links as a separate exposure that needs its own review before any sensitive data is shared through them.
Embedding authentication by plan
Guest authentication for embedding works on every plan, including open source, but SSO-based embedding requires Pro or Enterprise. If tenant users reach analytics through SSO-based embedding, confirm the plan before design begins and check the plan tier against your licensing. Confirm this against the current embedding documentation and a test instance.
Policy count per group and table
Confirm the number of policies a group and table combination can carry, since the documented model allows one policy per table and group pair. Map every restricted group against every table it reads and check that no table needs two rules for the same group. Where a design needs more than one filter, plan a single custom policy or a different isolation method.
Multi-tenant segregation requirements
Confirm that your tenant model works with attribute-based filters, since a single missing or incorrect user attribute can expose another tenant's rows. Test an account with a blank attribute, a changed attribute, and a user in two groups to see what the query returns. Record the expected behavior so that operations staff can reproduce it after upgrades.
Questions buyers ask before they hire help with row and column security
Which Metabase plan includes row and column security?
Row and column security is available only on the Pro and Enterprise plans, whether self-hosted or on Metabase Cloud. Open Source and Starter do not include it, so a self-hosted deployment that needs group-based row filters must be licensed at Pro or above. On Metabase's pricing page, Pro is listed at $575 per month or $517.50 per month billed yearly, with the first 10 users included and additional users at $12 per month each. Enterprise is priced by quote, starting at $20,000 per year. Confirm current terms with Metabase before budgeting, since list prices can change.
How much does a row and column security project cost?
The cost has two parts: the Metabase license and the services work. The license is recurring and depends on your plan and user count. Services are usually one-time work for designing groups and policies and testing them across groups, plus optional recurring review after schema or user changes. Costs rise with the number of tables, groups and table-group combinations, the use of custom SQL policies, and the number of identity sources feeding user attributes. DeployOpen does not publish a price list. Ask for a written, fixed-scope quote that lists each phase, the deliverables, and which items are one-time or recurring.
How long does Metabase row-level permission setup take?
The duration depends on the scope, so no fixed timeline applies to every deployment. The main drivers are the number of databases and tables with restricted data, how many groups and attributes must be modeled, whether any policies need saved SQL questions, how many environments require testing, and how quickly the client's data owners and approver can answer design questions. A fixed-scope agreement should state the schedule, the dependencies on client input, and the acceptance criteria. Ask for those in writing before work starts.
What does the client need to provide for this engagement?
Three roles are needed. Data owners must define which rows and columns each group may see and approve the policy logic for their data. Identity administrators must confirm how user attributes reach Metabase, whether through manual configuration or sign-in and directory sync; advanced LDAP group and attribute sync and SCIM provisioning require Pro or Enterprise. A named approver must make access decisions and sign off test results. The client also needs a non-production instance with representative data and a test account for each group, so policies can be checked before they reach users.
Can an internal team implement row and column security without outside help?
An internal team can do this if it has Metabase administration experience, enough SQL skill to write and check filters or saved questions, and identity administration skills to supply user attributes. The harder parts are usually first-time policy design across many groups, building a test plan that covers each group and table combination, and keeping policies current after schema or user changes. The license cost applies either way. Before deciding, estimate the staff hours needed for each phase, and check whether the team can keep the work going after the first rollout.
What is the difference between a basic row policy and a custom SQL policy?
A basic row policy filters rows on a single column, typically by comparing that column to a user attribute. A custom policy is based on a saved SQL question, which lets it filter on several columns and restrict or edit which columns a group can see. Metabase allows one policy per table and group combination, so overlapping rules need careful design. As an illustrative example, a sales region filter fits a basic policy, while hiding salary columns and filtering by both region and account owner may require a custom policy. Custom policies also need more testing after schema changes.
Does Metabase row and column security support multi-tenant deployments?
Multi-tenant data segregation is listed on Metabase's pricing page as included in Pro and Enterprise, alongside row and column level permissions. A multi-tenant design usually relies on a tenant key stored as a user attribute and applied as a row filter on each shared table. The design needs confirmation of how tenant identifiers are assigned, how new tenants are onboarded, and how cross-tenant access is tested. Ask the implementation partner to show the test cases used to confirm that one tenant cannot query another tenant's rows, including through saved questions and custom SQL.
What should a fixed-scope quote list for row and column security?
A useful quote lists the databases, schemas and tables in scope, the groups and user attributes to be modeled, and whether each policy is basic or custom. It should name the identity sources involved and the sync method used for attributes, the test plan and the test environment, and the sign-off process with the named approver. It should separate one-time design and build work from any recurring review after schema or user changes, and state the Metabase plan and license cost assumptions. Finally, it should list client responsibilities, exclusions, and the acceptance criteria that close the engagement.
How DeployOpen works on this
DeployOpen plans, builds, documents and supports Metabase row and column security inside your own infrastructure, whether self-hosted or in your cloud accounts. Engagements are fixed-scope, with the policy design, deliverables and timeline agreed in writing before work starts.
How we scope
- Confirm your Metabase plan, since row and column security requires Pro or Enterprise, self-hosted or on Metabase Cloud
- Map which user attributes, groups and tables need row filters and which columns each group may see
- Decide whether attribute-based row policies or custom SQL-based policies fit each table, and document the reason
- Agree in writing the groups, tables, policies and test cases that the fixed scope covers
How we build
- Configure one row policy per table and group combination, mapped to user attributes from your identity source
- Build custom SQL-based policies where filters span multiple columns or where columns must be restricted or edited
- Test each group against sample accounts to confirm rows and columns are hidden from questions, dashboards and embeds
- Record the policy matrix, attribute sources and test results so reviewers can trace every restriction
How we hand over
- Deliver a written permissions matrix listing each group, table, row filter and column restriction
- Provide runbooks for adding a new group, table or attribute without weakening existing policies
- Walk your administrators through the test cases so they can repeat them after each change
- Document the Metabase version and plan the work was built and tested against
How we support
- Retest row and column policies before and after each Metabase upgrade, since the policy set may need review
- Review new tables, groups and saved SQL questions for policy gaps on a schedule agreed in the retainer
- Support multi-tenant segregation changes through a retainer that covers ongoing policy maintenance
- Confirm the scope of any retainer in writing, including response expectations and upgrade coverage
