Apache Superset drill by and drill to detail setup

When Apache Superset drill by and drill to detail earn their place in a dashboard

Drill by and Drill to Detail earn their place when people reading a dashboard need to explore beneath an aggregate that the author did not anticipate, and building a new chart for every follow-up question is too slow. Drill by breaks a chart's value down by another dimension in place, while Drill to Detail opens the underlying rows behind a value. Both act on charts that already exist, so the decision for the owning team is whether users who can see a chart should also be able to explore below it. Keep dashboards fixed when the summary is the approved view, when the rows behind a number are sensitive, or when the audience should never reach individual records. Superset is an Apache Software Foundation project released under the Apache License 2.0 (Apache-2.0) with no paid edition, so the choice is about configuration and governance. The project is in active release, with 6.0.0 published on December 18, 2025 and 6.1.0 on May 13, 2026.

The DRILL_BY feature flag has been on by default since Superset 4.0.0, so many teams already expose drill by without a deliberate decision. Both features depend on role permissions, so review which roles can use them before rollout and confirm the exact permission names in the documentation for your version. Superset 6.0.0 supports both features in embedded mode and with DASHBOARD_RBAC. The UPDATING notes advise removing the required permissions from embedded roles that should not expose them, which means an embedded viewer role can gain drill access if nobody reviewed it. Check every role used for guest or embedded access, and confirm that each one still holds only the permissions it needs, before enabling drill on an embedded dashboard.

Each drill action sends an additional query to the warehouse, so a dashboard that was cheap to serve can generate much more load once users start drilling. Drill to Detail can return large row sets, so decide which datasets are safe to expose at row level and confirm with your database team how the engine handles repeated ad hoc queries. Test with the users who will drill, on the datasets and roles they will use, and record which charts allow drilling before wider release. Because drill access is controlled through flags and permissions, you can start with internal analysts on one dashboard, observe query volume and widen access once the pattern is clear.

Which drill option fits which audience

On a standard dashboard inside your own Superset, drill options let analysts move from an aggregated chart to the detail behind it without writing SQL. Drill by breaks a chart down by another dimension, and Drill to Detail opens the underlying records. The DRILL_BY feature flag has been on by default since 4.0.0, so confirm the flag state in your configuration rather than assuming it matches your policy.

Drill by: analysts can split a chart by another column in the dataset, and each change sends a new query to the warehouse.
Drill to detail: users see the raw rows behind a data point, so the grant determines who can read record-level values.
Role grants: the drill permissions sit on roles analysts already hold. Confirm the exact permission names in your release before granting or removing them.
Row level security still applies: drilled queries run against the same dataset, so RLS filters limit which detail appears.
Warehouse load: each drill adds a query, so decide which datasets are open to heavy drilling.

Before rollout, check which roles currently hold the drill permissions and test with a non-admin account against a dataset that has RLS filters.

Permissions that control drill by and drill to detail

Drill by and Drill to Detail let users go below a chart, so each action is gated by its own permission and by the dashboard and dataset access already in place. The cards below cover the role decisions, the embedded-role cleanup that 6.0.0 requires, and the checks to run before users see drill actions.

Map each drill action to a permission

Drill to Detail and Drill By are controlled by separate permissions in the Superset role model, so a role can have one without the other. Before rollout, list which roles should drill into raw rows and which should only pivot a chart by another dimension. Confirm the exact permission names in the Superset role documentation for your version, since names and default role grants can change between releases. Record the mapping so it can be tested later.

Remove drill permissions from embedded roles

Superset 6.0.0 supports Drill to Detail and Drill By in embedded mode, and the UPDATING notes advise removing the required permissions from embedded roles that should not expose them. Embedded viewers often hold roles copied from internal users, so a drill permission can reach them without anyone deciding it should. Audit each embedded role and remove drill permissions unless the product owner has approved drilling for that audience.

Check dashboard access before drilling

A drill action only returns data a user could already reach through the chart's dataset, so dashboard access and drill permissions must agree. A user who can open a dashboard but not its underlying datasets should not be able to drill into rows from those datasets. Test with a non-admin account on each dashboard tier, and confirm the behavior when dashboard-level RBAC is turned on, since that setting changes which dashboards a role can see.

Confirm row level security still applies

Row level security filters are applied to the queries that drill actions send, so a user drilling into detail should see only the rows their RLS rules allow. This matters most for drill to detail, where raw records can expose fields the summary chart hid. Test a restricted user on a drill path that crosses an RLS boundary, and compare the rows returned with what the same user sees in the chart.

Limit who can change datasets

Drill actions use the columns and dimensions defined on the dataset, so a user who can edit a dataset can change what a drill exposes. Restrict dataset edit rights to the team that owns the semantic model, and review changes to columns that hold personal or sensitive data. Confirm in the role documentation which permissions allow dataset editing for your version.

Record role changes for audit

Permission changes to drill access should be traceable, because a later drill exposure is hard to explain without a record of who granted it. Keep the role mapping, the embedded role review, and test results in version control or a change log. Ask your auditor which evidence they expect for access to detail-level data, and confirm which Superset event logs capture role and permission edits in your deployment.

How to enable and verify drill actions in Superset

This sequence confirms that drill actions are available in your Superset version, that the right roles can and cannot use them, and that the extra warehouse queries behave as expected. Each step closes with a check you can record before users reach production dashboards.

Confirm the Superset version in use
The platform or infrastructure owner confirms the exact Superset version running in each environment, including staging and production, from the About dialog in the user interface or the deployment manifest. Embedded drill support starts at version 6.0.0, so any embedded use case on an older release needs an upgrade plan first. Check is complete when every environment reports a version you have recorded and that version is confirmed against the release notes for your target.
Check the DRILL_BY feature flag
The Superset administrator reviews the DRILL_BY feature flag in the configuration file or environment settings for each environment. Drill By has been on by default since version 4.0.0, so a missing entry means it is enabled, while an explicit false value hides the drill menu on charts. Confirm the flag names and their current defaults in the configuration documentation for your version. Check is complete when you can open a chart in staging and see the drill option in the chart menu, or you have documented why it is absent.
Review embedded and DASHBOARD_RBAC roles
The administrator reviews the permissions assigned to every role that can view dashboards, including embedded roles and any roles evaluated under DASHBOARD_RBAC. Superset 6.0.0 supports Drill to Detail and Drill By in embedded mode and with DASHBOARD_RBAC, and the UPDATING notes advise removing the required permissions from embedded roles that should not expose them. Export the role list, mark each drill permission as allowed or removed, and get sign-off from the data owner. Check is complete when the role matrix matches the approved access model.
Test with a non-admin account
A tester signs in with a standard test account for each business role, not an administrator account, and opens dashboards built on governed datasets. Administrators see more than most users, so only a non-admin test shows what end users actually get. The tester tries drill by and drill to detail on the same chart for each role and records whether the option appears and whether the resulting view is limited to what that role may see. Check is complete when each role's result matches the matrix from the previous step.
Verify the drill queries sent to the warehouse
The data platform team reviews the queries that drill actions send to the database, using the database's query logs or the query history available to them. Drill actions add queries beyond the chart's original query, so confirm they run under the expected database account, filter as the role intends, and stay within the limits your warehouse team has set. Check is complete when logged drill queries match the chart's dimensions and filters, and the load they add is acceptable for the warehouse.
Record results and repeat after upgrades
The project owner saves the test matrix, the flag settings, the role export and the query log extracts together as a dated record for the release. Repeat the checks in staging before each Superset upgrade, reviewing UPDATING.md for changes that touch drill behavior or permissions. Check is complete when the record names the version, the tested roles and the approver, and the next upgrade has a scheduled re-test.

What extra queries drill actions add to your warehouse

Each drill action runs a new query against the underlying dataset, so warehouse load grows with how many users explore below a chart and how wide the detail rows are. A chart shows an aggregate that was already computed, but Drill to Detail and Drill By ask the database for rows or a further grouping at the moment the user clicks. Those requests are added to the queries the dashboard already sends, and they are not free because they reuse the same dataset and warehouse capacity your dashboards depend on.

Four drivers set the cost. The first is dataset size and query cost: a drill against a wide fact table with no supporting indexes or partitions is far heavier than a drill against a pre-aggregated table. The second is concurrency, since a single executive exploring one chart is cheap, while a team of a few hundred users clicking through the same dashboard after a morning refresh can saturate a warehouse with small queries. The third is caching, because repeated drills with identical filters may be served from Superset's cache depending on configuration, which you should confirm for your version. The fourth is how filters narrow results: a native filter or row level security rule that limits the rows before the drill runs reduces the scan, while an unfiltered dataset lets each click read far more data.

Superset does not publish a figure for how many drill queries a typical user generates, and the facts available here do not give one. Measure it in staging before you open drill to wider audiences. Enable query logging on the warehouse or use Superset's query history, run a representative set of drill paths as test users, and record query count, duration and rows returned per click. Then ask your warehouse team which concurrency limits and resource groups apply to the Superset service account, and set a target for peak drill load before rollout.

Security and governance risks when users can drill to detail

Drill by and Drill to Detail let users move from a summary into the rows behind it, so the controls around them matter as much as the chart. The cards below cover where exposure happens, which controls must pair with drill permissions, the embedded case, and what to confirm about logging before rollout.

Detail exposes more than the summary

A bar or pivot table may show totals only, but Drill to Detail opens the underlying rows of the dataset behind that chart. Those rows can include identifiers, free-text fields or amounts that the dashboard author never meant to publish at row level. Before enabling it, list the columns each dataset exposes and decide which ones a summary viewer should see in detail. Confirm this with a test user who has only the dashboard role.

Pair drill with row level security

Drill permissions control whether the action is available, not which rows it returns. Row level security filters still apply to the detail query, so a user who can drill into a region should only see that region's rows. Test with at least two accounts in different groups, and compare the detail rows against a direct query of the same dataset. Record which filters apply to each role.

Dataset access must match drill access

A user who can open a dashboard does not automatically have permission on every underlying dataset. Confirm that roles granting drill access also grant only the datasets and schemas those users are meant to query. Review charts that point to datasets in restricted schemas, since drilling from them can surface data the user could not browse directly. Check this during role design, not after dashboards go live.

Embedded and guest roles need explicit removal

Since Superset 6.0.0, Drill to Detail and Drill By work in embedded mode and with DASHBOARD_RBAC. The UPDATING notes advise removing the required permissions from embedded roles that should not expose them. Embedded viewers are often external customers, so an unnoticed permission can expose detail to users outside your organization. Verify the effective permissions of each embedded role after every upgrade.

Drill default changed in 4.0.0

Superset 4.0.0 turned on the DRILL_BY feature flag by default. A deployment upgraded from an earlier release may therefore offer drill actions that were never reviewed. Check the feature flag setting in your configuration and decide whether drill should be enabled for each audience. Document the decision alongside the roles it affects.

Confirm audit trail for detail queries

Drill to Detail sends extra queries to the warehouse, and those queries are what an auditor will ask about. Confirm with your team which Superset event and query logs record drill actions, which user identity is attached, and how long those logs are kept in your metadata store and warehouse. Do not assume detail access is logged in the same way as a dashboard view. Test a drill action and trace it through your logging stack before go-live.

Limits to confirm in your environment before rollout

Which chart types support Drill by and Drill to Detail in my Superset version?

Support depends on the chart type and the Superset version you run, so confirm it for each chart type you plan to publish rather than assuming it carries over from one chart to another. Build a test dashboard with every chart type your users rely on, enable the drill actions, and record which ones open and return correct rows. Keep the results with the version number, because a chart that works on one release may behave differently after an upgrade. Ask your DeployOpen team or your internal Superset owner to list the chart types in scope before the build starts, so the test matrix is agreed in writing with the rest of the scope.

Do drill permissions change after a Superset upgrade?

Treat every upgrade as a possible change to drill permissions and re-test them. Read the UPDATING notes for each version between your current release and the target release, and check whether the permissions that gate drilling, or the roles that hold them, have changed. Run the upgrade in staging first, then compare what each test role can see and do before and after. The upgrade documentation also asks you to back up the metadata database and run the standard upgrade commands, so drill checks belong in the same staging run as the database steps.

Does caching change what a drill action returns?

Caching can change what users see after a drill, so test drill actions with caching both on and off in your environment. A drill to detail request runs a query against the warehouse, and whether a cached result is reused depends on your cache configuration and on how the chart's query is built. Confirm with a test that a drill shows current data after the underlying table changes, and that the cache does not expose rows a user should not see. Record the cache settings used in each test, since changing them later can alter results without any change to the dashboard itself.

Which embedded roles should lose drill permissions?

Remove the drill permissions from any embedded role that should not expose them. The Superset 6.0.0 UPDATING notes state that drill to detail and drill by work in embedded mode and with DASHBOARD_RBAC, and they advise removing the required permissions from embedded roles that should not have them. Review each embedded role by name, check its permission list after every role change, and test with a guest user who holds only the embedded role. Pair this check with your row level security tests, since a drill can reveal rows that a dashboard filter hid.

Does the Superset 7.0.0 pre-release change drill behavior?

Do not plan a production rollout around the 7.0.0 pre-release. The GitHub releases page lists 7.0.0rc2 as a pre-release dated October 16, 2026, which means it is a release candidate and not a stable version. Teams planning ahead should read its UPDATING notes once a final release exists, then test drill actions in staging against that version. Until then, base the design on the version you actually run and the notes for the version you plan to move to.

Is Drill by enabled by default in current Superset releases?

Drill by has been enabled by default since Superset 4.0.0, which turned on the DRILL_BY feature flag by default according to the UPDATING notes. That default matters for older deployments that were configured with the flag off, because an upgrade can expose a capability your team never reviewed. Check the feature flags in your configuration file, confirm the effective value after each upgrade, and decide whether drilling should be available to every role that can open a dashboard.

How much does drill testing add to a rollout, and who pays for it?

The added effort depends on the number of chart types, the number of roles, the number of Superset versions in your upgrade path, and whether embedded dashboards are in scope. Drill testing is usually part of the overall build or upgrade work, so ask for it to appear as a separate line in the written scope and quote. Ask the partner to name the test cases, the roles covered, and the environments used. Ongoing re-testing after each upgrade recurs, so ask whether it sits in a retainer or a one-time engagement.

Can my own team confirm drill limits without a partner?

Yes, if your team has a staging Superset that matches production and at least one person who can read the UPDATING notes and manage roles. The work is a repeatable test plan: list chart types, define test users for each role, run drill actions with and without caching, and repeat the same plan after every upgrade. Teams without that capacity often ask a partner to build the test matrix once and hand over the scripts and results. Either way, the written record of what was tested and on which version is the artifact your auditors and security reviewers will ask for.

Decisions to settle before users see drill actions

Drill by and Drill to Detail change what a chart user can reach, so the governance decisions come before the feature is switched on for anyone beyond the build team. The first decision is which datasets allow detail. Drill to Detail hands users row-level records from the underlying table, which is a different exposure from the aggregated chart they saw before. For each dataset, record whether detail is allowed at all, which columns may appear, and whether row level security filters already apply to the drill query. The second decision is which roles get drill. Superset exposes these actions through role permissions, so the permission set for each role should be written down and reviewed against the access model you already run for dashboards. Confirm the exact permission names in your Superset version's documentation, since they are not restated here.

The third decision is how embedded tenants are isolated. Since 6.0.0, Drill to Detail and Drill By work in embedded mode and with DASHBOARD_RBAC, and the UPDATING notes advise removing the required permissions from embedded roles that should not expose them. Decide which embedded roles keep these permissions, and test one tenant's guest context against another tenant's data before go-live. The fourth decision is who owns the test plan. Name one owner who signs off on drill behavior per dataset, and include tests that check denied users, RLS-filtered users and embedded guests. The trade-off underneath all four is exploration freedom against warehouse load and data exposure. Each drill is an extra query, so broad permissions can multiply load on a shared warehouse, and generous detail access widens what a single user can extract. A DeployOpen scope would document these decisions in writing, per dataset and role, with the test cases and owner named, so your security and data teams can approve them before rollout.

How DeployOpen scopes and delivers drill and permission work

DeployOpen treats drill by and drill to detail as a permission and data exposure decision before it is a dashboard feature. We scope which roles may drill, test those roles in your own Superset environment, and hand over the role settings and runbook your team needs to keep them correct.

How we scope

The written scope lists which dashboards, charts and roles will allow drill by or drill to detail.
We confirm whether embedded dashboards or DASHBOARD_RBAC are in use, since those change which roles need the permissions.
Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.

How we build

We configure the DRILL_BY feature flag and role permissions to match the access model you approve.
We remove drill permissions from embedded roles that should not expose them, following the Superset 6.0.0 UPDATING notes.
We test drill paths with accounts from each role and review the extra queries they send to your warehouse.

How we hand over

You receive a role-to-permission matrix showing who can drill by, drill to detail, or both.
Documentation covers the query load drill actions add and the settings to review when charts change.
Your team walks through the test results and the checklist used to verify each role before go-live.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Permission reviews are repeated when Superset versions change, starting from the UPDATING.md breaking change notes.
We can retest drill paths after new roles, embedded tenants or dashboards are added to the environment.

Apache Superset drill by and drill to detail