Forum Discussion
Direct Lake Restrictions and Limitation
- 1 year ago
Hello Fantmas
The decision between Direct Lake and Import mode should be based on your specific data volume, refresh frequency requirements, technical capabilities, and tolerance for implementation complexity. For organizations with large datasets and technical resources to implement the necessary configurations, Direct Lake offers substantial benefits that may outweigh the additional complexity. For smaller implementations prioritizing simplicity and consistent performance, Import mode may remain the more pragmatic choice.
The root cause of App access issue , lies in how permissions propagate through the various layers of the architecture. When a user accesses a report through an App, they typically don't have direct access to the underlying Lakehouse data. However, Direct Lake's default behavior requires users to have appropriate permissions to the source data, leading to access denied errors.
The recommended solution would be to creating and using a service principal to mediate access between users and the Lakehouse data.
Microsoft has introduced controls that allow administrators to manage how Direct Lake handles fallback scenarios, providing more predictable behavior
https://fabric.guru/controlling-direct-lake-fallback-behaviorMicrosoft has expanded guidance on developing Direct Lake semantic models, including best practices for RLS implementation
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-develop
Hello Fantmas
The decision between Direct Lake and Import mode should be based on your specific data volume, refresh frequency requirements, technical capabilities, and tolerance for implementation complexity. For organizations with large datasets and technical resources to implement the necessary configurations, Direct Lake offers substantial benefits that may outweigh the additional complexity. For smaller implementations prioritizing simplicity and consistent performance, Import mode may remain the more pragmatic choice.
The root cause of App access issue , lies in how permissions propagate through the various layers of the architecture. When a user accesses a report through an App, they typically don't have direct access to the underlying Lakehouse data. However, Direct Lake's default behavior requires users to have appropriate permissions to the source data, leading to access denied errors.
The recommended solution would be to creating and using a service principal to mediate access between users and the Lakehouse data.
Microsoft has introduced controls that allow administrators to manage how Direct Lake handles fallback scenarios, providing more predictable behavior
https://fabric.guru/controlling-direct-lake-fallback-behavior
Microsoft has expanded guidance on developing Direct Lake semantic models, including best practices for RLS implementation
https://learn.microsoft.com/en-us/fabric/fundamentals/direct-lake-develop
what would you consider large? 100million rows?