Bring Your Own Storage (BYOS)
BYOS is an Enterprise plan capability that keeps your engagement telemetry entirely in storage you own, even when you run BI Pixie inside Microsoft Fabric. You run BI Pixie on Azure (BI Pixie's self-hosted edition) in your own Azure subscription, so your events land directly in your own Azure Data Lake Storage Gen2 account and BI Pixie never stores them. You keep the Workload experience to manage your reports, add Pixies, and install the BI Pixie Dashboard.
BYOS vs. OneLake delivery
In the Fabric Workload you have two data-residency options. Both keep your telemetry in your tenant; they differ in who runs the BI Pixie telemetry web trigger:
| OneLake delivery | BYOS | |
|---|---|---|
| Telemetry web trigger | BI Pixie hosts it, then delivers events to your OneLake | You host it; events never enter BI Pixie infrastructure |
| Where telemetry rests | Your OneLake lakehouse | Your own Azure Data Lake Storage Gen2 account |
| Setup effort | One-time consent in the BI Pixie item | You run BI Pixie on Azure |
| Best when | You want telemetry in your tenant with the least setup | Policy requires events never touch BI Pixie infrastructure |
OneLake delivery and BYOS are mutually exclusive on an account: enabling one disables the other. For a side-by-side of all storage options across BI Pixie, see the Data Residency overview.
How it works
- You run BI Pixie on Azure. You deploy BI Pixie on Azure (BI Pixie's self-hosted edition) in your own Azure subscription. It runs the BI Pixie telemetry web trigger and writes events directly to your own Azure Data Lake Storage Gen2 account.
- Point the Workload at your telemetry web trigger. A BI Pixie admin opens the BI Pixie item, goes to Account, and sets the self-hosted backend (your telemetry web trigger URL). From then on the Pixies in your reports send events to your telemetry web trigger instead of ours. Your telemetry never enters BI Pixie infrastructure.
- (Optional) Grant scoped read access. To use Event Viewer and Data Management over your own store, you grant BI Pixie least-privilege, revocable read access: a container-scoped RBAC role assignment (recommended; secret-free) or a container-scoped SAS. Without a grant, BI Pixie never reads your data; you keep adding Pixies to your reports and using the dashboard.
Granting RBAC read access (recommended)
RBAC is the recommended grant: nothing is stored as a secret, and you can revoke it at any time. It is three one-time steps in your own tenant:
- Consent to the BI Pixie app so its service principal — BI Pixie Delivery — exists in your tenant.
- Hold User Access Administrator (or Owner) on the storage scope so you can assign a role.
- Assign Storage Blob Data Reader to BI Pixie Delivery on your events container. In the Fabric Workload the grant is always read-only — BI Pixie never deletes your telemetry (deletion and retention run as your own notebooks).
Scope the role to the events container, not the whole storage account. A container-scoped grant is least-privilege, and keeps the assignment from interfering with import-mode (Power Query / M) refreshes that read the same account. BI Pixie only ever needs your events container.
One setup, all your licenses
BYOS is configured once for the account and applies to every license on it. Each license writes to its own folder inside your storage account, so business units stay cleanly separated while you manage a single backend. New licenses you create inherit the same self-hosted configuration automatically.
Your dashboard still works
BYOS does not change your dashboard experience. The Workload still performs the full immersive install (lakehouse, semantic model, report, and the Spark ETL notebook); the only difference is that the OneLake shortcut points at your own container instead of BI Pixie storage. The ETL and Direct Lake model are unchanged, so your BI Pixie Dashboard reads your own telemetry transparently.
Deletion and retention are yours
In the Fabric Workload, BI Pixie never deletes your raw telemetry. Any scoped access you grant is read-only, so Event Viewer and Data Management let you browse, search, and preview your data, but BI Pixie performs no destructive operations against your store.
When you need to delete data or apply retention (for example, GDPR erasure or trimming old events), you run BI Pixie's provided notebooks on your own Fabric capacity. Because those notebooks run in your tenant, under your control, BI Pixie is never the processor for deletion. This is the key difference from the Cloud portal, where you can optionally grant a read and delete tier; the Workload offers no delete grant.
Your data stays yours
- We never store it. Telemetry lives only in your Azure account; BI Pixie holds no copy.
- We never delete it. All deletion and retention run as your own notebooks on your own Fabric capacity.
- Revocable any time. Remove the RBAC role or let the SAS expire, or switch the account back to BI Pixie storage in-product, which also revokes our read access.
Full processing terms for BYOS, OneLake delivery, and BI Pixie storage are set out in our Data Processing Agreement.
What's Next
- Data Residency overview: compare all three storage options across BI Pixie.
- Data Residency (OneLake): store your engagement telemetry in your own OneLake lakehouse instead of the BI Pixie cloud.
- Data Management: browse, search, retention, and the customer-run deletion notebooks.