Skip to main content
Composite topics are currently in beta, but available on all Omni instances.
Composite topics — also called multi-fact tables — let you query across two or more independent topics in a single result set, sharing dimensions across them and filtering each topic by its own attributes. Each topic is aggregated independently in its own subquery, and the results are stitched together with a FULL OUTER JOIN on the dimensions and views you mark as shared. Because each fact stays in its own subquery, every measure is computed against the correct grain. The result is a single analysis surface that pulls fields and filters from every topic.

​
When to use a composite topic

Reach for a composite topic when both of the following are true:
  • You want measures from two or more fact tables in the same chart, table, or dashboard tile
  • The fact tables share at least one dimension you’d join on (date, customer, region, product)
If you only need measures from a single fact table — even if it joins to several dimension tables — a regular topic is the right choice.

​
Common patterns

​
Composite topics vs. XLOOKUP

XLOOKUP also lets you pull values from another query into the current one. For one-off, exploratory work, it’s often the faster choice. Composite topics are the right tool when the cross-fact analysis needs to be reusable, governed, and available to other users.

​
How it works

Each topic computes its measures independently. This means that results align on shared dimensions, ensuring there isn’t any fan out.

​
Field picker behavior

The workbook field picker organizes a composite topic’s fields into a few groups:

​
Limitations

  • Topic-specific dimensions cannot be in SELECT. They can only be used as filters; selecting one returns a query error. This is by design — there’s no outer GROUP BY to make the result deterministic.
  • Shared dimensions can map differently-named columns, but the values must align. Use mappings: to point each topic at its own field — the columns don’t need to share a name or SQL definition. They do need to represent the same logical value: if the underlying SQL differs in a way that changes the result (different timezone conversions, different casing, etc.), rows won’t align on the join even though the model validates.
  • Shared measures don’t re-aggregate. Each per-topic subquery aggregates first, then the shared measure runs over the joined result row-by-row. Wrapping a field in SUM(...) or setting aggregate_type: won’t re-aggregate the joined result — see shared_measures for details.
  • Filters on shared measures can’t be pushed down. They’re applied as a WHERE on the post-join result. This is correct, but means a filter on a shared measure won’t reduce the size of the per-topic subqueries.
  • Only topics with selected fields are included in the join by default. To improve query performance, Omni only includes topics with selected fields in the FULL OUTER JOIN. If you need all topics included regardless of selection, set always_join_all_topics: true.
  • Fields directives on included topics are enforced at query runtime. If an included topic excludes fields via the fields directive, those fields cannot be queried through the composite topic. Queries attempting to use excluded fields will return an error.
  • Access controls and AI context come from the included topics. Access grants, row-level security, and AI context defined on each included topic continue to apply when that topic is queried as part of a composite. The composite topic doesn’t support its own required_access_grants; control access by gating the included topics.

​
Known bugs

  • Errors when flattening a pivot on a shared dimension. If you build a pivot table on a composite topic where the pivot field is a shared dimension and click Flatten, the query returns No such topic <subtopic name>. A fix is in progress.

​
Roadmap

Composite topics are in beta and we want your feedback! We’re especially interested in:
  • Use cases that don’t fit — What cross-fact analyses are you trying to do that this doesn’t support?
  • YAML ergonomics — Is the shared_dimensions / shared_measures / shared_views shape intuitive? Are there parameters you expected to find?
  • Workbook UX rough edges — Confusing menus, unclear errors, missing affordances
  • Performance — Slow plans, surprising query shapes, cases where the subquery breakdown produces expensive SQL
Share feedback with your Omni representative or through Omni support.
See the following sections for future development plans for composite topics. If Omni plans to make breaking changes, we’ll publish a migration note before release.

​
Modeling

Remove @ from shared_measures syntax.

​
Workbook

  • Consolidate composite topics into the main topic picker. Composite topics appear in their own group rather than mixing into existing topic subfolders alongside regular topics. We plan to surface them together so end users don’t need to distinguish between the two.
  • Workbook-side editing for composite topics, similar to the topic editor for regular topics.
  • Promote a calculation to a shared measure. If you build a calculation in a workbook that combines fields from multiple topics, you’ll be able to promote it directly into the composite topic’s shared_measures block.
  • General workbook UI improvements

​
Agent support

Support interaction through Omni Agents. Natural language workflows, such as querying or modeling composite topics, aren’t currently supported.

​
Next steps