Maintenance Notebooks
Your BI Pixie telemetry in Microsoft Fabric lives across three layers that you own and run on your own capacity: the raw event files, the Lakehouse Delta tables the BI Pixie ETL builds from them, and the Direct Lake BI Pixie semantic model. To delete data for real, every layer that holds a copy must be cleared. BI Pixie ships two customer-run Fabric notebooks that do exactly that, across all three layers, under your own identity. BI Pixie never runs them for you.
- BI Pixie Data Retention: delete telemetry older than a window you choose, then compact and reclaim storage on the Delta tables and reframe the model.
- BI Pixie User Erasure: erase one end user's telemetry for a right-to-be-forgotten / GDPR request, then reframe the model.
BI Pixie installs both notebooks into a Maintenance folder under your BI Pixie workspace folder, alongside the dashboard, model, and ETL. You open and run them yourself, or schedule them with Fabric.
These notebooks are the only way to clear the Lakehouse and model layers, so they are required for complete deletion, not an optional extra. The Data Management page handles retention settings and event search; the notebooks carry out the deletion across every layer.
Why both notebooks exist
When you reduce retention or delete a user from the Data Management UI, that records your intent and clears the layer BI Pixie can reach directly. But the Lakehouse Delta tables and the Direct Lake model keep their own copies of the same telemetry, and those copies sit on your capacity, under your identity. BI Pixie cannot run code on your compute to delete them without becoming the processor of your data. The notebooks close that gap: you run them, so the deletion reaches every layer and the request is genuinely complete.
Safety: preview first
Both notebooks run in preview mode by default. They report how many rows (and raw files) would be removed and change nothing. To actually delete, set the DELETE parameter to True and run again. Nothing is removed until you do.
BI Pixie Data Retention
Removes telemetry older than a chosen window, then runs Delta maintenance and reframes the model. Open the BI Pixie Data Retention notebook from the Maintenance folder, set the parameters, and run.
| Parameter | What it does |
|---|---|
RETENTION_DAYS | Keep this many days of telemetry. Rows older than this are removed. Default 365. |
DELETE | False (default) previews counts only. True performs the deletion. |
OPTIMIZE_TABLES / VACUUM_TABLES | Run Delta OPTIMIZE (compaction) and VACUUM (reclaim storage) after a real delete. Default on. |
VACUUM_RETAIN_HOURS | File history VACUUM keeps. Default 168 (the 7-day Delta safety window). |
REFRESH_SEMANTIC_MODEL | Reframe the BI Pixie Dashboard model after changes so it reflects the deletes. Default on. |
The dashboard's summary tables are rebuilt in full on each ETL run, so they drop aged-out data on their own; the notebook focuses on the accumulating event and session tables.
BI Pixie User Erasure
Removes one end user's telemetry across every table that holds their rows, for a GDPR right-to-be-forgotten request. Open the BI Pixie User Erasure notebook, set the parameters, and run.
| Parameter | What it does |
|---|---|
USER | The user to erase, given as their email address (the User Key BI Pixie stores for signed-in users). You can find it in the Users table or on the dashboard. |
DELETE | False (default) previews matching rows only. True performs the erasure. |
REFRESH_SEMANTIC_MODEL | Reframe the model after the erasure so it shows immediately. Default on. |
The erasure covers the accumulating telemetry tables plus the rolled-up snapshots (feedback, survey, users, the user-to-IP map), so the request is complete when the notebook finishes. You do not need to run the BI Pixie ETL afterward. BI Pixie never stores a raw IP address: anonymous activity is keyed on a non-identifying hash, so a named request is keyed on the email address.
What each notebook deletes by backend mode
The notebooks always clear the Lakehouse Delta tables and the Direct Lake model (the layers no other tool touches) in every mode. What handles the raw event files depends on where your events are stored:
| Backend mode | Lakehouse + model | Raw event files |
|---|---|---|
| BI Pixie cloud (default) | The notebook | BI Pixie handles it (the raw events sit in BI Pixie's storage) |
| OneLake delivery | The notebook | The notebook (your events are a writable folder in your own lakehouse) |
| Bring Your Own Storage | The notebook | You remove them in your own storage account, using your own tools |
In every mode the notebook is what clears the Lakehouse and model. The raw-file step differs only because of where those files live and who can write to them.
Who can run them
The notebooks run under your own identity, on your own capacity, and only touch data in your workspace. Anyone with the workspace access to run a Fabric notebook can run them. Because you own the data and the action, BI Pixie is not the processor: BI Pixie ships the logic, you run it. See Team & Workspace Access for how Fabric workspace roles govern this.
What's Next
- Data Management — Retention settings, event search, and user activity in the BI Pixie item.
- Data Residency (OneLake) — Keep your raw events in your own OneLake.
- Bring Your Own Storage — Keep your telemetry in storage you own.
- BI Pixie Semantic Model — The Direct Lake model the notebooks reframe.