Data Studio is the modelling layer beneath xMatix analytics. Where the Analytics section covers consuming numbers — reports, dashboards, pivots — Data Studio covers governing them: reusable data models built once and shared, datasets shaped for analysis and rebuilt on a schedule, row-security declarations that live with the dataset, and archival rules that move cold history out of the working system. Define revenue once here, and everything downstream means the same thing by it.
The pipeline in one paragraph
Operational records live in entities. A data model joins entities (and archived or externally landed warehouse tables) into a governed, reusable structure and materializes it into the analytics warehouse — a managed warehouse provisioned for your organization. A dataset is built from a data model: named dimensions and measures over that structure, compiled into SQL and materialized as its own warehouse table on a refresh schedule. Datasets are what analysis consumes — dashboard widgets can read them directly. Archive rules feed the warehouse from the other direction, moving cold operational rows into archive tables that data models can also read. Every materialization step is logged, schedulable and inspectable.
Read the Dataset Builder
- 1
New Dataset creates the dataset shell — name, label, data model or fallback table, grain, refresh schedule and warehouse table.
- 2
Bound / Ready to backfill / Ambiguous / Unmapped / Missing source counts show which datasets lack a published-model binding.
- 3
Refresh Binding Check re-evaluates every dataset against published models; Apply Matched Bindings writes only unambiguous matches.
- 4
Binding, Refresh, Visibility and Active describe the dataset contract; Refresh type and Visibility are stored but do not change behaviour yet.
- 5
Open Workspace authors sources, dimensions, measures and filters; Edit reopens the shell dialog; Delete removes the definition.
The Dataset Builder is the working surface of Data Studio's consumption layer. The Dataset binding status panel reports how many datasets are bound to a published model and how many are unmapped, ambiguous or missing their source; the table below lists every dataset with its Data Model, Binding, Refresh type, Visibility, Active flag and last update, with Open Workspace, Edit and Delete on each row. New Dataset creates the dataset shell — the definition is then authored in the workspace. The build procedure is in Build a dataset.
What's in this section
| Page | What it covers |
|---|---|
| Build a dataset | The Dataset Builder end to end — sources, dimensions, measures, filters, compile, validate, preview and refresh |
| Data models and materialization | What a data model is, what building one produces, and how models relate to datasets |
| Row-level security on datasets | Row security rules — what a rule declares, how rules are validated, and how they relate to build-time filters |
| Archive rules | Rule-based archival — what qualifies, scheduling, and where archived data goes |
| Governed embedded BI | The embedded BI design — the asset allowlist and how datasets are meant to feed it (preview) |
| Refresh scheduling and monitoring | Cron schedules, what triggers a run, run statuses and history — for datasets, models and archive rules |
| Troubleshooting Data Studio | Stale datasets, missing rows, failed builds — the working method for each |
Where it lives in the product
Data Studio has two entry points, deliberately split by audience:
- Setup no longer carries a Data Studio section, and the org-wide analytics admin page that used to list every report and dashboard is gone with it: reports and dashboards are created, designed and deleted on the front end. Archive Rules lives under Setup → Process Studio (a rule runs on a schedule rather than defining anything analytics reads) and Consent under Setup → Access Control (it governs who may use whose data).
- Dataset Builder (
/analytics/datasets) and Data Model Builder (/analytics/data-models) are application pages, not Setup screens. Dataset Builder ships as a navigation item of the standard Analytics app, after Reports and Dashboards; Data Model Builder is available as a Feature navigation item that an administrator adds to an app (Setup → Apps → navigation items → type Feature → the route), so the people who model data work inside the app they already use.
Access follows those two shapes. The Setup screens are capability-gated — Analytics requires the analytics administration capability (setup.metadata.analytics.manage), Archive Rules the archive administration capability (setup.metadata.archive.manage) — so modelling and archival can be held by different people. The two builder pages are reached through app navigation: who can model data is controlled by which apps carry those routes and who can open those apps.
What Data Studio does not do yet
Two settings are recorded on a dataset but do not change behaviour in current releases, and it is better to know that up front than to discover it in production:
- Refresh type. Full and Incremental are both accepted, but every refresh is a full drop-and-rebuild of the warehouse table. Size schedules for full rebuilds.
- Visibility. Private, App and Shared are stored and shown, but nothing filters on them yet — dashboard designers see every active dataset.
Dataset security rules are likewise declarations that travel with the definition and appear in the preview; they are not applied to the compiled table, and no consuming surface applies them at read time yet either — use dataset filters or separate datasets when rows must genuinely be excluded. The details and the consequences are in Row-level security on datasets.
Common questions
What is the difference between Data Studio and Analytics?
Analytics is where numbers are consumed: dashboards, reports, pivots. Data Studio is the layer beneath — the data models, datasets, refresh schedules, security declarations and archival rules those consumers draw from. The practical consequence: when a number is wrong everywhere, the fix is usually one place in Data Studio, not a hunt through every report. See the Analytics documentation for the consumption side.
Do we need our own data warehouse or BI team?
No. Datasets and data models materialize into a managed warehouse that is provisioned and maintained as part of the platform — there are no pipelines to build or servers to run. What your organization supplies is the modelling judgment: which entities join into which models, which dimensions and measures matter, and what "cold" means for archival.
Who is told when a scheduled refresh breaks?
The dataset's creator. The first failed scheduled refresh sends an in-app notification and an email with the error; repeated failures stay quiet, and the next success after a failure sends one more message saying the dataset is healthy again. Data model builds and archive runs record their outcome in history but do not notify anyone — see Refresh scheduling and monitoring.