> ## Documentation Index
> Fetch the complete documentation index at: https://docs.omni.co/llms.txt
> Use this file to discover all available pages before exploring further.

# unrelated_dimension_handling - Composite topics

> Controls whether a member topic's own dimensions can be selected in a query, and how the other topics' measures line up against them.

Controls how a query can use a dimension that belongs to only a subset of member topics. This applies to any dimension that isn't a [shared dimension](/modeling/composite-topics/parameters/shared-dimensions) and isn't on a [shared view](/modeling/composite-topics/parameters/shared-views).

By default, these dimensions can only act as filters on a query. To make the dimensions selectable for the query, you can decide whether measure values should be represented as `NULL` or repeated when the dimension is not shared across all topics.

## Syntax

```yaml theme={null}
unrelated_dimension_handling: filter_only | null_fill | repeat
```

## Properties

<ParamField path="unrelated_dimension_handling" type="string" default="filter_only">
  * `filter_only` - **Default**. A member topic's own dimensions appear in the field picker as filter-only fields. A query that selects one anyway, for example through the API, returns an error.
  * `null_fill` - A member topic's own dimensions can be selected in the field picker. The other member topics' measures appear once per group, on a row where the dimension is `NULL`.
  * `repeat` - A member topic's own dimensions can be selected in the field picker. The other member topics' measures repeat on every row of the dimension.

  When a topic-scoped dimension is selected under `null_fill` or `repeat`, its column header in the results table shows an info icon that explains which mode is active.
</ParamField>

## Examples

The examples below use a composite topic with two member topics:

* `orders`: one row per order, with `status` (`complete`, `shipped`) and `sale_price`. Joins to `users`.
* `users`: one row per user, with `country`.

`users` is also a shared view, so `country` is available from both topics. `status` exists only in `orders`.

```yaml theme={null}
topics: [orders, users]
shared_views: [users]
```

Each example runs the same query: `country`, `status`, `sale_price_sum`, and `user_count`. Only the `unrelated_dimension_handling` value changes.

### `filter_only` (default)

```yaml theme={null}
unrelated_dimension_handling: filter_only
```

`status` is filter-only, so the query returns an error. Removing `status` from the selection returns:

| country | sale\_price\_sum | user\_count |
| ------- | ---------------- | ----------- |
| US      | 2000             | 340         |
| DE      | 500              | 90          |

### `null_fill`

```yaml theme={null}
unrelated_dimension_handling: null_fill
```

`user_count` lands on one extra row per `country` where `status` is `NULL`. `sale_price_sum` is `NULL` on that row because it's already accounted for on the `status` rows. Each measure appears once per `country`, so every column still sums correctly.

| country | status   | sale\_price\_sum | user\_count |
| ------- | -------- | ---------------- | ----------- |
| US      | complete | 1200             |             |
| US      | shipped  | 800              |             |
| US      |          |                  | 340         |
| DE      | complete | 500              |             |
| DE      |          |                  | 90          |

### `repeat`

```yaml theme={null}
unrelated_dimension_handling: repeat
```

`user_count` repeats on every `status` row for its country. Summing it across rows overcounts it, so use `repeat` when the value is meant to be read per row, for example as the denominator in a ratio.

| country | status   | sale\_price\_sum | user\_count |
| ------- | -------- | ---------------- | ----------- |
| US      | complete | 1200             | 340         |
| US      | shipped  | 800              | 340         |
| DE      | complete | 500              | 90          |

## Limitations

* **A `NULL` value coming from the table is indistinguishable from a filled-in row.** With `null_fill`, a value that is genuinely `NULL` in the data gets the same key as fill row. In the example above, orders with a `NULL` status have the key `US | NULL`, so their `sale_price_sum` shows up in the `US | NULL` row next to `user_count`. The result gives no way to tell whether that `NULL` is a real value or a fill. Filter out `NULL` values of the dimension if you need the fill row to be unambiguous.
* **Pivots, fill fields, and totals on topic-scoped dimensions aren't currently supported.** Pivoting on a topic-scoped dimension, filling its missing values, or requesting totals in a query that selects one returns an error.
* **The mode applies to every member topic.** It's set once on the composite topic and covers all member topics, including imported ones.