Drill through to record detail when a number is disputed

The exhibitor was polite about it, which somehow made it worse. Their lead retrieval export showed 2,187 scans at the stand. The report we had sent them said 2,340. They wanted to know which was right before they signed for next year.

Nobody in the room could answer. The 2,340 was a measure in a semantic model, and the path from that number back to any actual scan record ran through a data engineer, a query, and about a day and a half.

Drill through to record detail is the feature that closes that gap, and the reason to build it has nothing to do with analysis. It is about being able to settle an argument in the meeting where the argument happens.

Why does an aggregate get argued with?

Because an aggregate is a claim with its evidence removed, and the person on the other side of the table has their own claim with its evidence removed too. Two summaries cannot resolve each other. Only the rows can.

Kimball Group's published note on facts and grain, read on kimballgroup.com in August 2026, puts the underlying idea cleanly: "Facts are the measurements that result from a business process event and are almost always numeric. A single fact table row has a one-to-one relationship to a measurement event as described by the fact table's grain." The same note insists that a fact table corresponds to "a physical observable event, and not to the demands of a particular report".

Read that as a promise about what exists. If your scan fact table is at the grain of one row per scan, then 2,340 counts 2,340 things that happened, each of which has a time and a device and a badge, and none of it rests on anybody's judgement. The drill through page is the interface that makes that promise visible. Without it, the promise is technically true and practically unavailable, which from the exhibitor's point of view is the same as it not being true.

There is a second reason worth naming. A team that cannot open the rows behind its own numbers stops trusting them too, and the symptom is a shadow spreadsheet. Somebody in commercial keeps a parallel count because they can see how it was built. That spreadsheet then gets quoted in a board pack, and now there are two numbers with different provenance in circulation.

What the drill through page must return

Microsoft's drillthrough documentation on Microsoft Learn, dated March 2026, describes the mechanism plainly: "Drillthrough is a navigation feature that lets report viewers move from one page to another filtered to a specific value." Fields placed in the drillthrough filters well determine what the target page shows, and the tool adds a back button automatically once you add the first field.

The mechanism is easy. What goes on the target page is where the value is, and there are five things it needs.

A stable identifier per row. The badge number, the registration id, the contract line id. Something the reader can quote back and somebody else can look up in the source system. A row without an identifier is a row nobody can act on.

The source system. Which platform the record came from, named the way the operations team names it, because that is the first thing anybody asks when two counts disagree.

The timestamp. Both the event time and, if they differ, the load time. A record scanned at 16:42 and loaded at 03:10 the next morning explains a whole class of same-day discrepancies.

The fields that determined inclusion. If the measure counts distinct badges with a scan type of entry, then scan type and badge id both belong on the page, because those are the two things the reader will want to check.

The row count, displayed. A card showing how many rows the page is returning. This is the cheapest control in reporting and almost nobody adds it. If the reader clicked a tile reading 2,340 and the detail page shows 2,340, the model and the page agree. If it shows 2,417, something in the drill through filter differs from the measure filter and you have found a real defect.

Working the disputed count

Back to the exhibitor. The tile reads 2,340. Right-click, drill through, and the page opens filtered to that stand and that edition, returning 2,340 rows with the five things above.

Group the rows by source system and the answer appears immediately. Lead retrieval device rows: 2,187. Session scanner rows from the theatre inside the stand: 153. Add them and you get 2,340, which matches the tile, so the report is internally consistent.

Now the argument becomes the useful one. The exhibitor's export contains only their own device, which is why they see 2,187. The 153 are people who scanned into a session hosted on the stand and never presented a badge to the lead retrieval unit. Whether those 153 belong in a lead count is a commercial question with a real answer either way, and it is a far better conversation than which of two numbers is wrong.

The difference is 153 on 2,187, or about 7 per cent. That is the size of the definitional gap, measured, in the meeting, from the rows. Reconciling scan counts across feeds as a discipline in its own right belongs to the post-show reporting cluster and D11 owns it, but the drill through page is what makes the reconciliation take four minutes instead of a day and a half.

What can go wrong with drill through?

Four things, and three of them have simple causes worth knowing before you spend an afternoon debugging.

The first is that drill through does not appear in the context menu. Microsoft's troubleshooting guidance lists the usual reason: "Check that the field isn't aggregated (for example, summed or counted) in the source visual." The drill through field has to be present as a field in both the source visual and the target page's filter well. A card visual showing a measure with no dimension in it has nothing to drill on.

The second is cross-report drill through, which people reach for when the detail belongs in another report. The documentation is specific that it requires both reports to be published in the same workspace, that field names and data types must match exactly, and that it is only supported in the service rather than in Desktop. Every one of those is a thing that quietly stops being true after a workspace reorganisation.

The third is that the drill through page inherits filters you did not intend, or fails to inherit ones you did. The row count card catches this immediately, which is the argument for adding it.

The fourth has no easy fix, and it is the one that matters most for event data. If the measure is built on a summarised table rather than the atomic rows, there are no rows to return. A count of verified attendance computed from a nightly aggregate can be drilled to the aggregate and no further, and the reader will get a page showing one row saying 2,340, which is worse than no drill through page because it looks like evidence.

Who should be allowed to open the rows?

A drill through page is a row-level export surface with a friendly interface, and it should be designed as one.

The rows behind an attendance count are people, with names and email addresses and employers. The rows behind an exhibitor revenue figure are contract values by account. Both are things somebody in the building can see and plenty of people cannot, and a drill through page created for a good reason is a common route for that distinction to get lost. Row and object level access rules govern this properly and they have their own posts in this cluster, so the point here is narrower: decide the audience for the detail page at the moment you build it, and do not assume it inherits anything sensible from the summary page.

A workable default for exhibitor-facing reporting is to return the rows with the identifiers and the source system and the timestamps, and to withhold the personal fields unless the reader is on the organiser side. The exhibitor can still verify the count, which is the entire purpose, without the page becoming a lead export nobody approved.

Where this stops

Drill through proves what the warehouse holds. It says nothing about whether the warehouse holds the right things.

If your scan pipeline dropped 400 records because a device lost connectivity for an hour, the drill through page will return exactly the rows the count claims, every one of them checkable, and the count will still be wrong. The page makes the number auditable against its own source and offers no protection at all against a source that is incomplete. That is worth saying out loud to anybody who treats a working drill through as a data quality control, because it is a provenance control and the two get confused.

The second limit is practical. Drill through pages returning tens of thousands of rows are slow, and readers abandon a page that takes fifteen seconds. Above a few thousand rows the useful design changes: return a summary by source system and date with a further drill to the rows, which puts you back on a hierarchy question rather than a detail question.

Pick your most-argued-about measure this week and build one drill through page for it, with the five fields above and a row count card. Then click it from three different tiles and check the count matches each time. If it does not, you have found a filter mismatch that has been sitting in a report somebody quotes to exhibitors, and finding it is worth more than the page itself. Naming the measure so its filter travels with it, which is a related discipline, and putting its definition beside the number will stop most of the remaining disputes before they reach a drill through at all. All three belong in the same pass over your event business intelligence layer.