> ## Documentation Index
> Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Cube filters on limit KPIs
> How to enable or disable cube filters on limit KPIs in Atoti Limits using the limits.cube.kpi-filters-enabled property, with use case examples showing how filters affect evaluated limit values at different scope levels
## Overview
You can now enable/disable filters on limit KPIs when viewing the KPIs in the business cube.
This helps reduce operational risk where a user may see that a limit is passing, when in fact it is
in breach.
This feature does not affect the evaluation of limits via the UI or REST services, which in fact
operate as if the filters were disabled.
This feature also applies to the filtering effect of default MDX members in the configuration
of your business cube. Please see the [Atoti Server documentation](https://docs.activeviam.com/products/atoti/server/6.1/docs/mdx/mdx_filtering/#mdx-default-members) for more information on MDX default members.
## Configuration
KPI filters are enabled by default. This is to ensure behavior remains the same as previous versions
of Atoti Limits. To disable them, set the `limits.cube.kpi-filters-enabled` property
to `false` in your `application.yml`.
## Use cases
To illustrate the effects of enabling and disabling filters, consider the following pivot:
| Book | ID | PnL |
|---|
| Book 1 | 1 | 1000 |
| Book 1 | 2 | 2000 |
| Book 1 | 3 | 3000 |
| Book 2 | 1 | 1000 |
| Book 3 | 1 | 1000 |
We will create limits on the `Book` level at each of the `AllMember`, `Wildcard`, and `Book 1`
members. For cases 3-6 inclusive, we shall also apply a default MDX member of `ID = 1` to illustrate
the effect of overriding the default member at runtime.
### Case 1: A cube filter is set at the limit level
Here we apply a filter on `Book = Book 1` via the UI.
#### Enabled:
When filters are enabled, the `Book = Book 1` value should be used.
#### Disabled:
When filters are disabled, the true value of the `Book` level should be used.
#### Difference:
Notice the difference in the `AllMember` limit.
### Case 2: A cube filter is set below the limit level, contributing to the limit value
Here we apply a filter on the `ID=1` member.
#### Enabled:
When filters are enabled, only the `ID=1` member contributes to the limit value.
#### Disabled:
When filters are disabled, all `ID` members contribute to the limit value.
#### Difference:
Notice that when enabled, the limit value for all limits is `1000`. When disabled, the limit value is
the true unfiltered value for each limit.
The limit value is different from the actual `PnL` when filters are disabled. This is
because the filters are still applied to the rest of the cube, but not to the limit value. This behavior
will be visible in the following cases as well.
From now on, we also apply a default MDX member of `ID = 1`.
### Case 3: The default MDX member’s level is in view, meaning the MDX filter is not applied
When filters are either enabled or disabled, the true value will be used.
#### Enabled:
#### Disabled:
### Case 4: The default MDX member’s level is not in view, meaning the MDX filter is applied
#### Enabled:
When filters are enabled only the `ID=1` member contributes to the limit value.
#### Disabled:
When filters are disabled, all `ID` members contribute to the limit value.
### Case 5: A cube filter is applied, overriding the default MDX filter
Here we apply a filter on `ID = 2` via the UI.
#### Enabled:
When filters are enabled, only the `ID=2` member contributes to the limit value.
#### Disabled:
When filters are disabled, all `ID` members contribute to the limit value.
### Case 6: A query time MDX default member filter is applied, overriding the default MDX filter
Here we apply a query time MDX default member on `ID=2`.
#### Enabled:
When filters are enabled, only the `ID=2` member contributes to the limit value.
#### Disabled:
When filters are disabled, all `ID` members contribute to the limit value.
