QUALIFY *; UNQUALIFY CustomerID;
QUALIFY and UNQUALIFY in Power BI
QUALIFY prefixes field names with the table name so Qlik doesn't associate tables on shared names. Power BI doesn't associate tables on shared names at query time. Relationships are model objects, and the same column name can exist in several tables. Desktop's "Autodetect new relationships" option (Options > Data Load) can create relationships from matching names at load, so check the Model view or turn it off. Most QUALIFY statements can simply be dropped. If you want prefixed names, use Table.PrefixColumns.
What it does in Qlik
QUALIFY field_listrenames the listed fields, or*for all, totable.fieldin the following loads.UNQUALIFYexempts fields, usually the keys you do want to associate on.
Qlik example
QUALIFY *;
UNQUALIFY CustomerID;
Orders: LOAD * FROM orders.qvd (qvd); // Orders.Status, Orders.Date, CustomerID
Invoices: LOAD * FROM invoices.qvd (qvd); // Invoices.Status, Invoices.Date, CustomerID
UNQUALIFY *;Power BI equivalent
Usually: nothing
Load both tables as they are. In the Model view, create only the relationships you need, for example on CustomerID. Columns with the same name in different tables don't interact.
If you want prefixes
= Table.PrefixColumns(Orders, "Orders") // Orders.OrderID, Orders.Status ...
// rename the key back if you like
= Table.RenameColumns(Prefixed, {{"Orders.CustomerID", "CustomerID"}})Gotchas and behaviour differences
- "Autodetect new relationships after data is loaded" in Desktop options can create relationships on matching names, which is a little like Qlik's association. Turn it off and create relationships deliberately.
- Field names must be unique within a table, but not across tables. In DAX you always reference them as
Table[Column], which is effectively qualified.
Official documentation
- Qualify - script statement (Qlik Help)
- Unqualify - script statement (Qlik Help)
- Table.PrefixColumns (Power Query M) (Microsoft Learn)
- Create and manage relationships in Power BI Desktop (Microsoft Learn)
Related pages
$Syn tables (automatic)
Synthetic keys and associative linking
Qlik links tables automatically on every field with the same name and builds synthetic keys when they share several fields. Power BI doesn't link on every shared name. Relationships are model objects (autodetect may suggest some from matching names at load, so check them), use a single column and have a direction, so migrations usually remodel to a star schema.
No 1:1 equivalent
DROP TABLE Temp; RENAME FIELD Cust TO Customer;
DROP and RENAME (tables and fields)
Dropping a temporary table in Qlik maps to a staging query with Enable load unchecked. It feeds other queries but doesn't reach the model. DROP FIELD maps to Table.RemoveColumns, and RENAME FIELD to Table.RenameColumns. Qlik's "RENAME FIELDS USING map" maps to Table.RenameColumns with a list built from a mapping table.
Direct equivalent
[Inner|Left|Right|Outer] Join / Keep
Join and Keep
Qlik joins on all fields with the same name, and a plain Join is a full outer join. Power Query merges need explicit key columns and a join kind. Keep filters a table without merging, which maps to a semi-join filter or an inner merge you don't expand.
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.