Forum Discussion
Composite Model based on DirectLake over OneLake and Import tables
Hi jaryszek , Thank you for reaching out to the Microsoft Fabric Community Forum.
You are correct that Import mode does allow you to use Power Query, and within Power Query you can define parameters to filter rows before they are loaded. This is exactly how you can control the amount of data that gets imported into your model. The distinction I was making is that those parameters only take effect at refresh or load time, they don’t provide dynamic filtering at query time.
This is where the difference with Direct Lake comes in. Direct Lake does not allow Power Query transformations at all, which means you cannot apply parameters when connecting those tables. If you want Direct Lake tables to only expose certain rows, you need to prepare that filtered dataset upstream in OneLake, either by creating a materialized Delta table or a SQL analytics endpoint view.
Finally, if your requirement is not just to reduce the imported dataset but also to control which rows individual users see, then parameters are not the right tool. That scenario is handled with Row-Level Security (RLS), which applies dynamic row filters at query time after the data has already been loaded.
Direct Lake overview - Microsoft Fabric | Microsoft Learn
Parameters - Power Query | Microsoft Learn
Row-level security (RLS) with Power BI - Microsoft Fabric | Microsoft Learn
Hi jaryszek , Thank you for reaching out to the Microsoft Fabric Community Forum.
When you import tables from OneLake into a semantic model, they are always brought in as a complete dataset unless you apply a filter during the import. Unlike DirectLake or DirectQuery, Import mode does not support dynamically restricting rows through parameters or partitioning. The filtering must happen either upstream in the Lakehouse or during the Power Query load process.
If your aim is to reduce the amount of data that gets imported, you can use Power Query parameters to restrict rows at load time. Parameters can be defined in Power Query and referenced in filter steps so that only a subset of the data is stored in the model. Another approach is to filter directly at the source by creating a SQL view in the Lakehouse SQL endpoint. In that case, you only import the view, which already applies the necessary restrictions.
If instead your goal is to restrict which rows users can see after the data has been imported, configure Row-Level Security (RLS) in the semantic model. RLS enforces row filtering at query time but does not change what is stored in Import mode.
Parameters - Power Query | Microsoft Learn
Row-level security (RLS) with Power BI - Microsoft Fabric | Microsoft Learn
What is the SQL analytics endpoint for a lakehouse? - Microsoft Fabric | Microsoft Learn