Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Important
This feature is in Public Preview.
Dashboard relationships let you define a semantic model scoped to an AI/BI dashboard. With dashboard relationships, you can create complex data models that span multiple fact and dimension tables by specifying how dashboard datasets relate to one another. They also let you create reusable measures that span multiple fact tables or other datasets. For example, you can join Orders, Shipments, and Returns fact tables through conformed dimensions and define cross-fact measures at the model level.
Instead of pre-joining data in SQL or duplicating join logic across datasets, you model relationships once and use them across all visualizations in the dashboard. Because dashboard relationships create a traversable graph between your datasets, they let you flexibly slice fields and measures across any connected dataset.
Dashboard relationships are dashboard-scoped and do not create a Unity Catalog object. Use them for prototyping, dashboard-specific analysis, or when you want to iterate before promoting logic to Unity Catalog. For metrics that must be governed and shared across dashboards, Genie Agents, or other tools, use Unity Catalog metric views instead. See Unity Catalog metric views. To compare dashboard relationships with the other data modeling options in AI/BI dashboards, see Choose the right approach.
To create relationships and cross-dataset measures, see Create dashboard relationships.
What problem do relationships solve?
Dashboard relationships enable multi-fact, multi-grain analysis without manually pre-joining data. Before relationships, an author who wanted to show orders revenue and shipments cost side by side, grouped by region, had to pre-join both fact tables to the region dimension and aggregate carefully to avoid fan-out. That logic lived in SQL, duplicated across every dataset that needed it. With relationships, the author defines the join once. The query engine decides what to join at runtime, based on the fields in the visualization. There's no fan-out, double-counting, or duplicated SQL.
Supported data models
Dashboard relationships perform query-time joins between tables based on the specified cardinality of the relationship. You can join fact tables through a conformed dimension, but not directly to each other through many-to-many joins.
Supported patterns include snowflake schemas, where a fact table joins a chain of dimensions, and shared dimensions, where two fact tables join the same conformed dimension. Ambiguous join paths, where a fact table can reach the same dimension through more than one path, and cyclic relationships aren't supported. You can resolve both by aliasing a dimension or table so that each join path is distinct.
Why field order matters
The first field you add anchors the root of the query graph, and every field after that is resolved relative to that root. The query engine walks the many-to-one edges out from the root and offers only what's reachable. You can slice by any dimension up a chain of many-to-one relationships, and you can pull measures from any fact table (each fact table aggregates independently and joins on the shared dimensions). Anything not reachable that way is unavailable.
The most common case is slicing one fact table's measure by another fact table's column. The two fact tables only meet at the shared dimension, so the field you select first decides which fact table is the root, and therefore whether the other fact table's columns are reachable. The same column can be available or unavailable depending on which field you selected first. For example, ship mode is unavailable when you start from orders revenue, but it's a valid grouping field when you start from ship mode.