Preview. The embedded BI surface described here is designed and partly built, but the embedding service is not enabled in current deployments: the Analytics viewer shows No analytics reports are available and the Setup inventory is empty. This page documents the governance model so that administrators know what the surface is for and what it will and will not decide; it does not describe a flow you can complete today.
Alongside its native reports and dashboards, xMatix is designed to surface content from a governed embedded BI workspace — professionally authored BI reports and dashboards, rendered inside the application rather than in a separate tool. The arrangement is deliberately one of curation: an operator-maintained allowlist decides exactly which BI assets may appear, viewers never need accounts with the BI tool, and the content is expected to be built over the warehouse tables that Data Studio datasets materialize — so the embedded numbers are the same governed numbers as everywhere else.
Where embedded BI appears
Two places, split by audience:
- The Analytics viewer — an application page (
/analytics) that renders an embedded BI report full-page inside xMatix. Users open it from their app navigation like any other page; the platform brokers access with short-lived embed tokens issued to the platform's own service identity, so there is no separate BI sign-in. With nothing embeddable, the page shows the alert No analytics reports are available. - Setup → Data Studio → Analytics, on its Analytics tab — the administrator's inventory of the workspace: Analytics Reports (Name, Dataset ID, Link) and Analytics Datasets (Name, Configured By, Refreshable), the latter with a Refresh action that triggers a BI-side model refresh. These BI-side semantic models are a different thing from Data Studio dataset records, despite the shared word.
The allowlist is the governance
What may embed is not "whatever exists in the workspace" — it is an explicit allowlist of BI assets, maintained as environment configuration by the platform operator. The enforcement is strict in both directions:
- Assets not on the allowlist do not appear in listings, and a direct embed request for one is refused outright.
- A report qualifies either by being allowlisted itself or by being backed by an allowlisted BI model — so allowlisting one governed model approves the family of reports built on it.
- An empty allowlist is a valid, locked-down state: nothing embeds until something is expressly approved. This is the state every deployment is in today.
The intent behind the mechanism: embedded content should be backed by materialized Data Studio dataset tables, not by ad-hoc connections into operational data. The allowlist is how that intent is enforced — an asset gets approved when it draws from the governed layer.
How datasets are meant to feed it
Datasets materialize into tables in the analytics warehouse. BI models in the embedded workspace are then authored over those tables — that authoring step is a deliberate decision by whoever builds the BI content, not an automatic link, which is exactly what keeps the surface curated. Freshness follows the same chain: a dataset refresh updates the warehouse table, and the BI model is refreshed to pick the new data up — from the Setup inventory's Refresh action on the model, on demand. Dataset refresh scheduling itself is covered in Refresh scheduling and monitoring.
What embedded BI does not decide
Who can open the viewer is decided inside xMatix — page navigation and permissions, like any other application page. What the embedded content contains is decided by the BI model it was built over; where the workspace has row-level roles configured, the signed-in user's identity can be passed through so the BI model scopes rows per viewer. Those are different controls: approving an asset onto the allowlist makes it embeddable for the users who can reach the viewer, so curate with that audience in mind, and prefer content built over datasets whose scope already matches it.
Common questions
The analytics viewer says no reports are available — why?
Because nothing is currently embeddable for your organization. In current deployments this is the expected state: the embedding service is not enabled, so the allowlist is effectively empty. It is the locked-down default, not an error, and there is no setting in Setup that changes it — the surface becomes available when the platform operator enables the service and approves assets.
Can we embed any dashboard from our BI tool?
Only assets on the allowlist, once the surface is enabled. That is the point of the governance: the embedded surface is curated, so content reaches users' screens deliberately, approved because it draws from the governed dataset layer — not because it happens to exist in the workspace. Native dashboards with dataset-backed widgets are the available path for putting Data Studio numbers in front of users today.
The embedded report shows stale numbers — what refreshes what?
Two refreshes are in play, in order. The dataset refresh materializes fresh data into the warehouse table on its own schedule. The BI model then needs its own refresh to read that table's new contents — trigger it from Setup → Data Studio → Analytics → Analytics with the model's Refresh action. If the embedded report lags the platform's own reports, the second refresh is almost always the missing step.