How each file is tracked, and how the Files report stays clean and current
This topic explains the single most important rule behind the Files report: one file, one row, always the latest action. Understanding it is what lets you trust every count, donut and tree map on the page.
ℹ The Files report is a current-state view, not a history log. It answers “what is actually in there, right now?” — the full history of a file lives on the per-file Action history (drill-through), not as duplicate rows.
—-
One file, one row — always the latest action
A file appears in the Files report exactly once. Each file carries a Status — the CurrentState field, also exposed as a slicer — that reflects the most recent action taken on it:
Discovery ReportDiscovery WorkspaceMigrationOffloadRestore
As a file moves through its lifecycle the status is updated in place. The same row changes from, for example, Discovery Report → Migration when the file is migrated. The file is never duplicated; you always see it under the latest action that applies to it.
—-
Re-discovery after migration — the status does NOT regress
Suppose a file already has status Migration and a later Discovery job encounters it again. The status does not fall back to Discovery Report — a migrated file stays migrated.
The status only reacts when the file has actually changed in the source. In that case the Modified after migration column is stamped with the new source timestamp, so it is immediately visible that the file is both (a) already migrated and (b) changed at source since — your candidate for delta-migration.
In the File details table these files are shown with a yellow background.
—-
How files turn up in the report — the run-history list controls everything
Every job writes its file-level output to the BI tables in the configured reporting database (PostgreSQL or SQL Server). What actually appears in the report is governed by the Run History list:
- Each run-history item represents one job run that touched a set of files.
- If a file is referenced by more than one run-history item, the most recent reference wins — that single instance is what you see.
- Exception: when a Discovery job re-references an already-migrated or offloaded file, the status changes only if the timestamp is newer (see above). A routine re-scan does not revert a migrated file.
The run-history items are exposed directly as a slicer, so you can filter the whole page down to a single job run.
—-
From the report straight to the job in Microsoft Teams
Each file record in the report carries a link to its associated Run History item in Microsoft Teams. If you have the report and access to the Content Governance team, you can click straight through from a file to its Run History item — and from there to the job that produced it, where you can review it, modify it, or re-run it.
ℹ This closes the loop between analysis and action: you spot something in the report (a library that didn’t migrate, a set of files that changed at source) and jump directly to the job that handles it, instead of hunting for it by hand. Access to the Microsoft Teams team is required to open the linked item.
—-
Self-cleaning — empty and deleted run-history items disappear
When every file that a run-history item used to reference has moved on to a newer status — for example all of its Discovery Report files are now Migration — that item no longer references any file. At that point it is dropped from the report and from the slicer; there is nothing meaningful left to show for it.
Likewise, when you delete a run-history item, every file still referenced only by that item leaves the report with it. This is the simplest way to prune the report by hand.
✓ Between “latest action wins”, the automatic dropping of empty run-history items, and manual deletion of items you no longer want, the Files report stays tidy and current over time — with no orphaned history items.