Sum({1} Sales) / Sum({<Region=>} Sales)

Ignoring selections: {1}, Field= and {1<...>} in Power BI

How to translate Qlik's {1} set identifier and empty field modifiers (Region=) into REMOVEFILTERS, ALL and ALLSELECTED. Includes the important difference in how chart dimensions are treated.

Partial / different approach DAX

Short answer: {<Region=>} is CALCULATE([Sales], REMOVEFILTERS(Customer[Region])). {1} is close to REMOVEFILTERS(), but DAX also removes the visual's own grouping, so you have to add the row dimension back.

What it does in Qlik

The set identifier 1 means "all records in the app, ignoring every selection". An empty modifier such as <Region=> clears the selection in that one field only.

In both cases the chart dimensions still apply. In a chart by Product, Sum({1} Sales) still shows each product's own all-time sales.

Qlik example

Qlik chart expressions

Sum({1} Sales)                     // ignore all selections
Sum({<Region=>} Sales)             // ignore only the Region selection
Sum({1<Year={2024}>} Sales)        // ignore everything, then force Year = 2024
Sum(Sales) / Sum({<Product=>} TOTAL Sales)   // share of selected total

Power BI equivalent

Ignore one field

DAX

Sales any region =
CALCULATE ( [Sales], REMOVEFILTERS ( Customer[Region] ) )

Ignore everything but keep the visual's row

REMOVEFILTERS() with no argument clears all filters, including the ones a visual applies for each row. To copy {1} in a visual by Product category, add the row value back with VALUES. VALUES is evaluated in the outer (row) context.

DAX

Sales ignore slicers =
CALCULATE (
    [Sales],
    REMOVEFILTERS (),
    VALUES ( Product[Category] )   -- the visual's dimension(s)
)

Share of the selected total (ALLSELECTED)

For "percent of what is selected", ALLSELECTED removes the visual's grouping but keeps the slicer selections. That is usually what TOTAL plus a cleared dimension was doing in Qlik.

DAX

Share of selected =
DIVIDE ( [Sales], CALCULATE ( [Sales], ALLSELECTED ( Product[Category] ) ) )

Gotchas and behaviour differences

The biggest trap: CALCULATE([Sales], ALL(Product)) in a visual by Product returns the grand total on every row. In Qlik, Sum({1} Sales) still splits by the chart dimension.
A Qlik measure is tied to its chart. A DAX measure is reused by every visual, so a hard-coded "add back the dimension" measure only works in visuals that group by that column. For general use, consider a visual calculation or separate measures.
REMOVEFILTERS and ALL are interchangeable as CALCULATE modifiers. ALL can also be used as a table function, while REMOVEFILTERS cannot.
Qlik's {1} also ignores selections in alternate states. Power BI has no states; see alternate states.

Official documentation

Set identifiers (Qlik Help)
Set modifiers (Qlik Help)
REMOVEFILTERS function (DAX) (Microsoft Learn)
ALLSELECTED function (DAX) (Microsoft Learn)
ALL (dax.guide)

Sum({<Field={value}>} Sales) Set Analysis basics How a basic Qlik set expression such as Sum({<Year={2024}>} Sales) maps to CALCULATE with filter arguments in DAX, and where the two engines behave differently. Direct equivalent Sum(TOTAL Sales) / Sum(TOTAL <Category> Sales) The TOTAL qualifier Qlik's TOTAL qualifier makes an aggregation ignore the chart dimensions but keep the selections. In DAX that is ALLSELECTED. TOTAL <Field> keeps one dimension, which maps to removing only the other dimension columns. Direct equivalent {<Field+={x}>} / {<Field-={x}>} / {<Field*={x}>} Set modifier operators: =, +=, -=, *= Qlik set modifiers can replace, extend, reduce or intersect the user's selection in a field. Here is how each assignment operator maps to DAX, using KEEPFILTERS, TREATAS and UNION. Partial / different approach Sum({StateName} Sales) Alternate states (comparative analysis) Alternate states give objects independent selection sets, for example comparing two groups of regions side by side. Power BI has one filter context per visual, plus disconnected tables and measures that apply them with TREATAS. There is no built-in "state" concept. Partial / different approach

Spotted an error or a better pattern? QlikToDax is maintained by a working BI consultant; corrections are welcome via the About page. Last reviewed 2026-10-25.