Power BI and the data platform underneath it
Most reporting problems are not reporting problems. They are pipeline and definition problems that surface as a dashboard nobody trusts. The work here is the whole stack: getting data out of the operational systems reliably, agreeing what the numbers mean once, and building reports measured by daily use rather than by how they look in a screenshot.
What this practice covers
Pipelines and reporting infrastructure that turn operational systems into decisions. ETL into warehouses, semantic models that survive contact with the business, and dashboards measured by daily use rather than screenshot quality.
The pipeline comes first. Operational systems are built to run the business, not to be reported on, so getting data out of them dependably, on a schedule, with failures that announce themselves rather than quietly producing yesterday's numbers again, is the unglamorous foundation everything above it stands on.
The semantic model comes second, and it is where most reporting projects are won or lost. It is the layer that says what an active deal is, when a month closes, and which margin is the margin, once, so that every report inherits the same answer instead of each one deciding for itself. Without it, two reports disagreeing is a matter of time.
The reports come last, which is the opposite of how these projects usually get scoped. A dashboard is only worth building once somebody can say which decision it is for and who makes it, and the measure of success is whether that person opens it unprompted.
Dynamics 365 and Power BI together
The most common shape of this work is a CRM and a reporting layer that were never designed to agree. Dynamics 365 holds the pipeline, project and accounting systems hold what actually happened, and the connection between what was sold and what it earned is reconstructed by hand each month by somebody with a spreadsheet.
Closing that loop usually means work on both ends. The CRM has to be shaped to the sales process the business actually runs, otherwise the data going in is wrong in ways no reporting layer can correct, and the reporting model has to span systems rather than sit on top of one. HDS has delivered both halves of that in the same engagement rather than only the reporting side.
The result worth aiming at is a single view where pipeline activity and delivered margin sit next to each other. That is the question leadership is actually asking, and it is the one that no single source system can answer alone.
Shipped, not proposed
Anonymized by client request. The Power BI engagement in full carries the problem and the build, alongside the rest of what HDS does.
Mid-market concrete contractor
Sales pipeline and project operations data lived in disconnected systems. No closed loop between Sales-stage activity and on-the-ground project metrics.
- Dynamics 365 Sales rebuild aligned to the actual sales process
- Power BI semantic model and dashboards across Sales + Operations
- Foundation ETL pipeline integrating CRM, project mgmt, and accounting
Closed sales/ops data loop. The CEO, the President of Concrete and the COO are in the dashboards every business day, on a platform licensed for fifteen, alongside nineteen dispatch users on the scheduling app. Ops leadership sees pipeline-to-project-margin in one view.
What it is built on
Power BI, Dynamics 365, PostgreSQL, Python, Supabase. Power BI and Dynamics 365 where the business is already on Microsoft, which is most of them, and Postgres, Python and Supabase where the pipeline has to reach systems Microsoft never intended it to. The tooling is chosen to fit what you already run rather than to justify a migration, and if your reporting is fine and your CRM is the problem, that is what gets said in scoping. Happy to talk about your reporting before anybody proposes anything.
Questions this practice gets asked
Our dashboards exist but nobody opens them. What went wrong?
Usually the report answers a question nobody actually has. Dashboards built from what the data can easily show, rather than from the decision somebody makes on a Monday morning, get admired once and abandoned. The fix starts with the decision and works backwards, which sometimes means deleting most of what is already there.
Do we need a warehouse or can Power BI read our systems directly?
Direct connections are fine while one system holds the answer. The moment a number has to combine CRM, project management, and accounting, doing that join inside report queries means every report re-implements the business logic slightly differently, and the versions drift. That is the point a warehouse and a shared semantic model stop being overhead.
Why do two reports give two different numbers for the same thing?
Because the definition lives in the reports rather than in one place above them. When each report decides for itself what counts as an active deal or a closed month, they will disagree eventually, and the argument that follows is about the numbers rather than about the business. A semantic model exists to make that definition singular.
Can you work with the Dynamics 365 setup we already have?
Yes, and that is a common starting point. Sometimes the reporting problem turns out to be a CRM problem, where the data is missing or inconsistent because the system was never shaped to the way the business actually sells. Rebuilding that alongside the reporting layer is work HDS has delivered rather than only recommended.
How do you know whether it worked?
By whether people open it without being asked. Daily use by the people who make the decisions is the only measure that means anything, and it is the one worth agreeing on before the build rather than after.
Which number does nobody in the business currently trust?
Start with a free scoping conversation with Mike Hyams, the person who builds and supports the work.