Power BI consulting, from the semantic model to the number finance signs

The semantic model, before the visuals

Every Power BI estate we're asked to fix has the same shape. Forty reports, each with its own copy of the revenue measure, three of which disagree by the time the CFO asks.

The fix is one semantic model, a star schema with the grain written down, measures agreed with whoever owns each number, and row-level security that follows the org chart. The reports read that model and nothing else. It's slower in week one and faster every week after.

• Star schema with conformed dimensions, so a date is a date in every report
• Measures defined once in DAX and agreed with the owner of the number before a visual exists
• Row-level security by entity, region or warehouse, tested with the people it restricts
• A benchmark set of questions with known answers, run again after every model change

Power BI on Databricks

Power BI Desktop connects to a Databricks SQL warehouse through Partner Connect or by hand, and as of September 2026 the two choices that decide whether it holds up are authentication and mode. OAuth for a person, a service principal for unattended refresh, or Microsoft Entra ID single sign-on so a Unity Catalog grant follows the viewer.

Import for a model that fits in memory, DirectQuery for one that doesn't. A Power BI task in a Lakeflow job can refresh the semantic model once a Power BI connection exists in Unity Catalog, which ties the refresh to the pipeline instead of to a clock.

• Service principal for refresh, so a report doesn't stop working when its author leaves
• Entra ID single sign-on where row and column filters live in Unity Catalog, so Power BI inherits them
• Refresh triggered from the Lakeflow job that lands the data, rather than a schedule guessing when it did
• Metric views read through DirectQuery with a native SQL query and MEASURE(), since Microsoft removed the compatibility mode from the connector

Power BI on Dynamics 365

The report that decides whether an ERP project felt worth it is the one finance and operations both read without arguing.

We build Power BI on the Business Central and Dynamics 365 CRM record, with the measures for margin, aged debt and inventory turns agreed with finance before the first visual, and the refresh scheduled against the posting cycle so Monday's number is Friday's close.

AmTab's modernisation put Power BI over data flowing between nopCommerce, CRM and the ERP, and that study is at /case-studies/amtab. The Dynamics practice itself is at /expertise/microsoft-dynamics-365.

• Semantic model on the ERP tables, rather than on a nightly export to Excel
• Measures reconciled to the trial balance before anyone sees a chart
• Row-level security matching company, warehouse or sales territory
• Dynamics implementation and reporting from one team, so the model knows what the posting groups mean

Power Automate and Power Apps

A report that shows a purchase order stuck for nine days is useful. A flow that routes it to the person who can approve it is what gets it unstuck. We build Power Automate for the approvals and handoffs that cross systems, and Power Apps for the data entry screen a process needs that the ERP doesn't have.

At AmTab the flows carry data between nopCommerce, CRM and the ERP in both directions, and a customer action can trigger the email or the promo code without anybody in the loop.

• Approval flows that carry the record they approve, so the decision is auditable
• Alerts from Power BI thresholds into Teams or email, with the query that fired them
• Power Apps for the form the process needs, on the same Dataverse tables the reports read
• Flows documented and owned, because an orphaned flow is a common way a process quietly stops

Microsoft Fabric, when it fits

Fabric can mirror an Azure Databricks Unity Catalog with no data movement, and Power BI builds a Direct Lake model straight on the mirrored tables. Databricks federates a Fabric Lakehouse the other way. So an estate on Azure doesn't have to pick a side.

It has to decide which platform holds the tables and which one reads them, and how we make that call is written up at /blog/fabric-or-databricks-is-the-wrong-question. We build on both, and we'll say which one should hold your tables before either of us has committed to it.

• Direct Lake models on OneLake where the estate is already in Fabric
• A mirrored Unity Catalog where Databricks holds the tables and Power BI needs them without a copy
• Capacity sized against the actual refresh and query load, rather than the licence tier
• One semantic model whichever platform holds the data, so a move later doesn't rewrite the reports

Tableau to Power BI

A Tableau workbook doesn't convert into a Power BI report. The calculations, the level-of-detail expressions and the extract logic have to be remodelled as a semantic model and DAX, and a migration that treats it as a file conversion ships forty reports that are each slightly wrong.

We start with the inventory, which reports are opened and which haven't been since last year, then rebuild the model once and point the reports that survive at it.

• Inventory of workbooks by actual usage before anything is rebuilt
• Level-of-detail expressions and table calculations remodelled as measures, then reconciled against the Tableau figure
• A parallel run where both tools show the same number before the old one is switched off
• Licence and capacity costs compared on your usage rather than on the list price