Drill-downs — click-through navigation between reports
Drill-downs are click-through navigation between reports. A parent shows aggregated data — counts by customer, totals by region; the user clicks a row, lands in a target report filtered to that exact slice. This lesson is the integration moment for Module 7: aggregates, sorts, non-visible fields, Data Prep, and library structure all working together to make a polished drill-down report.
By the end of this lesson
- A working parent → target drill-down where clicking a field in the parent lands you in a filtered detail view
- The pivot-drill-down variant (different config path through the Pivot Grid)
- Clear understanding of the Hidden folder pattern and why it's best practice, not required
- Awareness of the multi-report permission rule and the move-vs-copy trap that breaks links
You'll need
- A working detail-level report you can use as the target — easiest with the one from Lesson 3
- A field on that report that will serve as the link between parent and target (customer, status, anything categorical)
- Permission to create folders and set folder-level permissions — see groups-folders for the mechanics
Background
A drill-down is a click target on a field that opens a second report, automatically filtered to whatever value was clicked. The terminology:
- Parent report — the summary view the user opens first. Counts by customer, totals by region, ranked top-25, whatever the high-level shape is.
- Target report — the detail view the user lands in after clicking. Same dataset typically, but with all the per-row detail the parent aggregated away.
- Drill-down field — a special column on the parent that displays a value (usually the same value as another column) but is wired to navigate to the target when clicked. Renders with a hyperlink look so users know it's interactive.
Drill-downs do two important things at once:
Drill-downs also work from inside charts (click a bar in a column chart → drill to filtered detail) and from inside pivots (click a cell in a pivot grid → drill with both the row and the column value applied as filters). The drill-down field on the parent is what powers all of these.
This lesson covers two ways to add a drill-down: the standard Field Builder path on a regular grid (most common), and the alternate path through Data Prep → Pivot drill-down options (simplified, two-criteria default — covered in makeItReal). Both produce the same kind of result; you'd pick the second when your parent is already in a pivot shape.
Stuck on something specific — picker won't show your target, permission errors on click, drill-down breaks after moving reports? Skip ahead to the pitfalls below. Most issues have a named cause and a one-line fix.
Do it
-
Build the target report first
Open the Composer and build the detail-level view that the user will land in after clicking. This is the report with every per-row column you want exposed when someone drills in: the ticket number, the open time, the agent, the channel, the resolution notes — whatever makes the detail useful.
Don't worry about Top N or aggregates here. The target is the raw detail view; the parent will handle the summary. Save the report. Give it a clear name like Tickets — Detail (drill-down target) so future Composers know what it's for.
The target should have at minimum the field you intend to use as the link — typically the same field the parent will group by (customer, status, region). The drill-down configuration in step 6 needs to map a value from the parent's clicked row to a filter on the target; that field needs to exist in both.
-
Decide where the target lives — Hidden folder is best practice
The target is now saved somewhere in your library. Most likely you don't want users running it directly — it's the unfiltered 72,000-row detail view, expensive and not useful out of context. The standard pattern is a Hidden folder.
Important framing — these are independent levers:
Hidden is a visibility setting, not a permission mechanism. Users still need folder permission for the drill-down click to work — Hidden just removes the folder from their library navigation. The two toggles cooperate to produce the standard "can-click-through-but-can't-browse" behavior.
The setup, mirroring the video: in your library tree, create a new folder called Target Reports (or any name you like) under wherever the parent will live. In the folder configuration, assign permission to All Users (or whichever group can see the parent). Expand Additional Options and toggle Hidden ON. Save. Move your target report into that folder.
The folder mechanics — All Users, group permissions, Hidden — are documented in detail in groups-folders.
-
Start the parent report FROM the target (best practice)
Open the target you just saved. Save As to create a copy you'll repurpose as the parent. Why work this way? It guarantees the linking field already exists in both reports — the parent and target share the same dataset selection, so any field you use to map between them is present in both.
You don't strictly have to start from the target — you could build the parent independently with the same dataset and ensure the linking field manually. But starting from the target makes the field-existence guarantee automatic. Mistakes here are silent (the drill-down configures fine but fails at click time because the field isn't in the target).
Once you've Saved As to a new report name, you'll see all the target's fields in your new parent. The next steps strip those down to a summary view.
-
Hide fields you'll want later — don't delete them
Most of the target's fields aren't needed in the parent's summary display. The temptation is to delete them. Don't.
Use the non-visible pattern instead — open each field's action menu, uncheck Visible. The field stays in the data flow but doesn't render in the grid. The reason matters:
- Hidden parent fields can become dashboard filters in Module 11. When the parent is embedded in a dashboard, the dashboard's filter widgets can target any field that exists on the report — visible or non-visible. Delete the field and that filter slot disappears.
- Hidden parent fields also pass down through drill-downs as filters on the target. If a user is filtering the parent by Channel = "Email" at the dashboard level, that filter cascades into the target report when they click through. Delete the field on the parent and the cascade stops working.
Keep every field the target has. Hide the ones the parent doesn't need to display. The dashboard module covers the cascade mechanic in detail; for now, just leave hidden fields in.
-
Add the parent aggregate, sort, and column labels
This is where the parent earns its summary shape. Three things:
- Add an aggregate. The standard one is
COUNT(?)on the ticket-ID (or primary-key) field — covered in Lesson 4. The result: one row per group, with a count column. - Add a sort. Sort descending on the count column to put the biggest groups first. The parent typically reads "biggest categories at the top."
- Rename the count column to something friendlier. The default label might be "Count of Ticket Number" — change it to "Number of Tickets" via the action menu's Label field.
Run the preview. The parent should now show one row per group, with a count column descending. This is the summary shape; what's missing is the drill-down field that makes the rows clickable.
- Add an aggregate. The standard one is
-
Data Prep → Field Builder → Drill-down field
Click Data Prep → Field Builder. The dialog opens with two field-type options:
- Drill-down field — what we're building. Navigates to a target report inside DashboardFox when clicked.
- External browser link — opens an external URL in a new tab. Useful for jumping to a CRM record, ticketing system, or any external tool with the clicked value as a parameter. Covered in its own lesson.
Pick Drill-down field. The configuration dialog asks for four things:
The dialog has an accordion at the bottom labeled Advanced Settings. Leave it closed unless support directs you to use it — it's for edge cases like translating between data formats (uppercase customer names in one app, mixed case in another). 99% of drill-downs never touch it.
Click Save, then Save and Apply on the parent report.
-
Hide the duplicate column and Save As to a user-visible folder
Two cleanup steps before this is done.
First: the parent now has both the original Customer column and the new Drill-down column displaying the same value. Open the original Customer column's action menu, uncheck Visible. The grid now shows only the Drill-down column with the hyperlink-styled customer values.
Quick test: click one of the drill-down values. You should land in the target report, filtered to just that customer's records. The row count in the target should match the count column in the parent for that row. If it matches, the drill-down works.
Second: save the parent to a folder users can see. The transcript demonstrates this with Save As into the main Customer Support Reports folder (not the Hidden Target Reports folder). The parent is the user-facing report; the target stays hidden and is only reachable by clicking through.
You now have a working drill-down setup. The next blocks cover the integration scenarios.
You have a working connection. Below is what to tighten before real users see it. Skip if you're just testing.
Make it real
Where drill-downs show up beyond the basic grid pattern, plus the cases you don't have to use them at all.
The same drill-down works inside a chart
Take the parent you just built and convert it to a column chart (action menu → Show as Chart → Column). Click a bar. The drill-down fires — you land in the target filtered to that bar's category. Same with line chart points, pie chart segments, area chart regions.
This is one of the biggest practical wins of the drill-down pattern: build the parent once with a drill-down field, then visualize it however the audience wants, and the drill-down behavior follows automatically. Charts inherit the parent's drill-down configuration.
The Module 8 lessons (charts, pivot-grid) go into more detail on chart-specific drill-down behavior and the visualization types that work best with it.
The pivot-drill-down variant — different config path
If your parent is a Simple Pivot (covered in the previous lesson), Field Builder isn't the way to add a drill-down — the Pivot dialog has its own drill-down option built in.
Build a pivot report (e.g. status as column, customer as row, count as data field). In Data Prep → Pivot, you'll see a drill-down option appear below the column/row/data configuration. Pick a target report, then map the pivot's column and row dimensions to fields on the target (status from pivot column → status on target; customer from pivot row → customer on target). Save and apply.
Now every cell in the pivot grid is clickable. Click "377" in the Open column for Shoplite Grocery, and you land in the target filtered to Customer = Shoplite Grocery AND Status = Open. Two filters auto-applied because the pivot has two natural dimensions.
This is the simplified-config path: pivot drill-downs always do two-dimensional filtering because pivots always have a column and a row. The standard Field Builder path through Block 3 is for grids; this is for pivots. Same underlying mechanic, different configuration UX.
Anonymous (guest) drill-downs need Public View on both reports
If you're publishing the parent in a guest library (covered in Module 5) for anonymous users, the drill-down needs additional setup.
- The target's folder also needs Allow Anonymous turned on. Otherwise, anonymous users can't enter the folder when the drill-down resolves.
- The target report itself needs Allow Public View turned on. This consumes one of your Public View licenses — same as any other anonymous report.
- The hardcoded-criteria rule from the guest lesson applies to both parent and target. Anonymous users have no row-level security; criteria have to be baked into the report definition.
Net effect: each anonymous drill-down setup costs two Public View licenses (one for parent, one for target), not one. Plan capacity accordingly. The guest library lesson covers the full anonymous setup; the drill-down-specific pitfall ("guest drill-down works for me as admin but anonymous users see permission errors") is in Block 5 below.
Some visualizations don't need data-grid drill-downs
Calendar, treemap, and geomap visualizations have native drill-down behavior — clicking a date, a treemap rectangle, or a map region drills naturally without needing a Field Builder drill-down field on the underlying grid. If you're building one of these, you don't have to add a drill-down field at all; the visualization handles it.
The viz types that DO benefit from a data-grid drill-down field include KPIs, line charts, bar charts, column charts (single and stacked), pie charts, and area charts. For those, the drill-down field on the parent makes the chart interactive in the same way the grid is. Module 8 — other viz types covers which visualizations have native drill behavior and which need the field.
If you're stuck
The drill-down pitfalls, in roughly the order they show up. The move-vs-copy trap is the most damaging; most teams discover it the hard way when they relocate reports from a private to a team library.
My target isn't showing in the picker
The target wasn't saved yet, or it's saved in a folder you don't have permission to see while building. Open the target, confirm it's saved, confirm you can browse to it in the library. If it's in a Hidden folder, that's fine — you (the builder) can still see Hidden folders if you have folder permission; only end users with permission have it hidden. Re-open the Field Builder dialog and the picker should now show it.
Users get "permission denied" when clicking the drill-down
They don't have folder permission to the target. Hidden status is irrelevant here — Hidden controls whether they can see the folder in their library tree; it doesn't affect whether they can run reports inside. Open the target folder's permissions and add the user's group. The drill-down click will then resolve normally. The "users can see parent but not target" mismatch is the most common cause of this error.
Filters from my dashboard aren't reaching the target when users drill through
You deleted parent fields instead of hiding them. The dashboard filter cascade requires the filtered field to exist on the parent (visible or non-visible, doesn't matter) — that's what gives the dashboard a slot to filter through. When the drill-down fires, the active filters on the parent pass down. Delete the field on the parent and the filter has nothing to attach to.
Fix: re-add the deleted field as non-visible on the parent. The drill-down mapping itself doesn't need to reference these fields — the cascade is independent. Module 11 — dashboard filters covers the full pass-through mechanic.
My drill-down column shows the alias name instead of the field value
You typed the field reference into the Display Value field by hand instead of using the mini-tree picker. Auto-generated aliases like svc_8066 look guessable but they're not — a single character off and the display silently falls back to the alias text. Open Field Builder, clear the Display Value, click the field-picker icon, expand the mini-tree, pick the field. Composer drops the correct reference in. Save and Apply.
Column Header rejected — "name already in use" or similar
The column header must be unique within the report. If you've named it Customer and the parent already has a Customer column, that's the collision. Give it a different name — Drill-down, View Detail, Open, or qualify it with the action verb. The hidden original Customer column doesn't help (it's still part of the report); you need a name no other column uses.
I moved my reports from a private to a team library and drill-downs broke
The most damaging pitfall and the one most teams discover the hard way. Two scenarios:
- You copied the parent and target into the team library. Each copy got a new report ID. The parent's drill-down configuration still references the original target's ID — the one still sitting in your private library. Users clicking the drill-down try to resolve a target they can't see, and get a permission error. Visually identical to a missing-permission issue; root cause is different.
- You moved the reports correctly. Move preserves the report ID, so the parent's drill-down configuration still resolves to the same target — which is now in the team library where users can reach it. This is the supported workflow.
Use Move, not Copy, when promoting drill-down sets between libraries. If you have to Copy (e.g. you want to keep the original in the private library as a backup), you'll need to re-open the copied parent in Composer, open the drill-down field via Field Builder, and re-point the Target Report to the new (copied) target. Same for any chained drill-downs — every parent in the chain needs its Target Report reference updated to the new IDs.
If the link is already broken in production, the symptom is permission errors for everyone except the original builder. Run the parent yourself, observe whether you see the same error (you usually won't, because you still have access to the private-library original). That confirms the diagnosis. The fix is to re-point or re-create the drill-down on the copied parent.
Anonymous users get permission errors clicking through a guest drill-down
The parent has Allow Public View; the target doesn't. Both need it. Each consumes one Public View license — plan capacity accordingly. Also confirm the target's folder has Allow Anonymous on (otherwise anonymous users can't enter the folder when the drill-down resolves). The guest library lesson covers the full anonymous setup; the drill-down case is its multi-report variant.
Field Builder asks about Advanced Settings — should I configure them?
Almost certainly no. Advanced Settings is for edge cases where the linking values don't match exactly between parent and target — for example, the parent has customer names in mixed case ("Acme Corp") and the target has them in uppercase ("ACME CORP"), so the default equality match fails. The Advanced Settings field lets you wrap the linking value with a function (UPPER(), TRIM(), etc.) to normalize before matching.
If you're hitting that situation, talk to your App Builder — usually the right fix is upstream (normalize the data in the App Builder's formula fields layer) rather than per-drill-down. If you genuinely need it, contact team@dashboardfox.com and they'll walk you through the syntax.
None of these match my situation
Email team@dashboardfox.com with the parent and target report names, what behavior you expect on click, and what's actually happening. A screenshot of the error or grid helps. Same business day reply.
