Tenant isolation

Views are always tenant-scoped and an App cannot opt out — what that guarantees, what it does not, and what you should still not put in a declared view.

You never configure isolation or storage in analytics.json. The platform always scopes each view to the tenant that queries it, so a view can only ever return that tenant's rows. That is not something an App can opt out of, and there is no field in the contract that would let you try.

Storage strategy is the same kind of decision: whether a view is served directly or held in a prepared form is a platform matter, not an app one. You declare what is analysable and where each column comes from — never SQL, never security or storage knobs.

What the guarantee covers

  • Rows. A query against analytics.acme__warehouse__locations on tenant A returns tenant A's locations. There is no parameter, no filter and no mistake in your declaration that changes that.
  • Every surface. The same scoping applies wherever the dataset is reached — the dataset picker, a chart, a cohort.
  • Without your involvement. You do not add a tenant column, you do not filter on one, and you should not try. A tenant column of your own is redundant at best.

What it does not cover

Isolation is about rows, not about columns. Three things it does not do for you:

It does not decide whether a column should be visible at all. Every operator who can open Analytics Studio for their tenant can see every column of every dataset registered for it. If a column holds something only some of that tenant's staff should see — a cost price, a margin, a personal detail — isolation does not help you, because those people are inside the tenant.

It does not classify personal data. A column carrying an email address or a name is exposed to anyone in the tenant who opens the dataset, and it will be in charts people export. Declare the identifier, not the person: an entity role wants a stable id, and a customer id serves a cohort just as well as an email address does.

It does not make a view a safe audit trail. A view is a projection for analysis. It is not a record of who looked at what.

What not to put in a view

A short list, worth reading before you declare columns:

  • Secrets and tokens. Obviously — but check for the field your app uses to hold a per-tenant integration key.
  • Raw personal data where an id would do. Prefer a customer id over a name and an email.
  • Free text that users typed. It is not a usable dimension, and it is the field most likely to contain something nobody meant to publish.
  • Internal state that only means something to your app's implementation. It confuses the operator and pins you to your current internals — a rename becomes a breaking dataset change.
  • Anything you would not show the customer's whole back-office team. That is the actual audience.

The reverse concern: your own data

The same isolation that protects the tenant protects you. A view you declare is registered per tenant and returns only that tenant's rows, so declaring analytics over your app's tables does not expose one customer's data to another — and it does not expose anything to you either. Declaring a view is not a way to read across your installed base; it is a way to put each tenant's own data in front of them.

If you need aggregate insight across your customers, that is your own telemetry, collected on your side with the customer's agreement — not an analytics.json view.

Where to go next

Was this page helpful?