Direct Lake Semantic Models — Restore Full Developer Visibility and Editing Capabilities in Power BI
As a senior Power BI Data Analyst and consultant, I am raising a critical developer experience gap introduced by Direct Lake semantic models that is significantly impacting my ability to do my job effectively.
The following capabilities — which are standard and essential in Import and DirectQuery modes — are missing or broken in Direct Lake:
1. TABLE VISIBILITY IN THE LEFT PANEL (DESKTOP)
When connected to a Direct Lake semantic model in Power BI Desktop, tables are not visible in the left-hand Data panel. This is a fundamental requirement. I need to see my tables to validate data, spot anomalies, check row counts, and verify that upstream data engineering has loaded correctly. Without this, I am building reports completely blind.
2. TABLE/DATA VIEW IN THE SERVICE
The Power BI Service does not expose underlying table data in a browsable view. When a Data Engineer makes a pipeline change that introduces a data type mismatch, incorrect values, or broken relationships, I have no way to detect this from within the semantic model. I should not need to leave the Power BI environment and open a SQL analytics endpoint just to inspect my own model's data.
3. DATA TYPE MANAGEMENT
I cannot change or correct data types on Direct Lake tables in either Desktop or the Service. Data type issues are a daily reality in analytics — source systems change, ETL pipelines evolve, and the BI developer is often the last line of defence before incorrect data reaches an executive dashboard. Removing this capability removes a critical quality control mechanism.
4. CALCULATED COLUMNS IN DESKTOP
I cannot add calculated columns to a Direct Lake semantic model in Power BI Desktop. Calculated columns are a legitimate and widely-used modelling tool, particularly for categorisation, banding, and label generation logic that belongs in the semantic layer — not hardcoded in upstream SQL or ETL pipelines.
The broader issue is a philosophy problem: Microsoft appears to assume that the Data Engineer and the BI Developer are always separate people working in perfect coordination. In reality, many Power BI professionals span both roles, and even in team environments, the BI developer must be able to validate, inspect, and augment the semantic layer independently.
Direct Lake is a genuinely powerful technology. But the current developer experience is a significant regression for professional Power BI developers who have built workflows around Desktop-first development over many years.
I urge Microsoft to restore these capabilities as a priority. Power BI's strength has always been empowering analysts to work with confidence and visibility. Please do not take that away in the name of cloud-first architecture.
