QlikToDax

{<Product={"Bike*"}>} / {<Customer={"=Sum(Sales)>10000"}>}

Searches in set modifiers (wildcards, >, aggregated conditions) in Power BI

How Qlik searches inside set modifiers (numeric ranges, wildcards and expression searches such as "=Sum(Sales)>10000") translate to DAX filters, and why the expression search needs ALLSELECTED to match.

Partial / different approach DAX

Short answer: Numeric and wildcard searches become boolean or FILTER conditions on a column. An expression search becomes FILTER(VALUES(Customer[Key]), [Sales] > 10000), but Qlik evaluates it once per chart, so wrap it in ALLSELECTED to get the same numbers.

What it does in Qlik

A search string in double quotes selects every value of the field that matches. It can be a wildcard ("Bike*"), a numeric comparison (">1000"), or an expression search ("=Sum(Sales)>10000"). An expression search evaluates the expression for each field value and keeps the values where it is true.

Text searches are not case-sensitive.

Qlik example

Qlik chart expressions
Sum({<Amount={">1000"}>} Sales)
Sum({<Product={"Bike*"}>} Sales)
Sum({<Customer={"=Sum(Sales)>10000"}>} Sales)

Power BI equivalent

Numeric and wildcard conditions

DAX
Sales big lines =
CALCULATE ( [Sales], Sales[Amount] > 1000 )

Sales bikes =
CALCULATE (
    [Sales],
    FILTER ( ALL ( Product[Name] ), LEFT ( Product[Name], 4 ) = "Bike" )
)

DAX text comparison with = is case-insensitive, like Qlik search. For "contains", use CONTAINSSTRING(Product[Name], "bike").

Expression search, the Qlik way

Qlik decides which customers qualify once for the whole chart, using the current selections. To get the same result in a visual grouped by, say, Year, compute the qualifying list under ALLSELECTED() and intersect it with the row.

DAX
Sales of big customers =
VAR Qualifying =
    CALCULATETABLE (
        FILTER ( VALUES ( Customer[CustomerKey] ), [Sales] > 10000 ),
        ALLSELECTED ()
    )
RETURN
    CALCULATE ( [Sales], KEEPFILTERS ( Qualifying ) )

The shorter CALCULATE([Sales], FILTER(VALUES(Customer[CustomerKey]), [Sales] > 10000)) re-tests the threshold inside every cell. In a visual by Year, that means "customers above 10,000 *in that year*". That may be what you want, but it is not what Qlik computes.

Gotchas and behaviour differences

  • Qlik's "Bike*" is anchored (it means "starts with"). DAX SEARCH("Bike*", ...) supports wildcards but finds matches anywhere in the text, so test the position or use LEFT.
  • A numeric search such as ">1000" on a field compares the field's distinct values, not individual rows. On a fact column like Amount, that is the same as a row filter.
  • FILTER over a whole fact table is slow. Filter a single column (ALL(Product[Name]), VALUES(Customer[CustomerKey])) instead.

Official documentation

Related pages

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 {<Customer=P({<Product={'Bike'}>} Customer)>} P() and E(): possible and excluded values Qlik's P() and E() functions answer questions like "sales of customers who ever bought a bike" or "customers who never did". In DAX you build the customer list with CALCULATETABLE and apply it with TREATAS or EXCEPT. Partial / different approach Sum({<Year={$(=Max(Year))}>} Sales) Dollar-sign expansion in sets: $(=Max(Year)) Dollar-sign expansions such as $(=Max(Year)) put a calculated value into a set expression. In DAX you use a variable, but it is evaluated per cell, not once per chart. Partial / different approach Avg(Aggr(Sum(Sales), Customer)) Aggr (nested aggregation) Aggr builds a virtual table of aggregated values, for example sales per customer, so you can aggregate again. In DAX that is an iterator (AVERAGEX, MAXX, COUNTROWS(FILTER(...))) over VALUES or SUMMARIZE that calls a measure. 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.