SQL
Power Query
OBBC Connections
DAX
Project 1
Sales Performance Dashboard
Tools Used
Power BI
Overview
An automated sales dashboard built in Power BI, using a live ODBC connection to the company ERP system. SQL statements were written to extract and shape sales, item, and customer data into a clean, always-current reporting layer.
What it does
Gives the sales and management team a single view of year-on-year performance, regional sales trends, and product-level breakdowns — updated automatically without manual data pulls. Used by both the sales team for dealer conversations and the marketing team to inform geo-targeted advertising decisions, ensuring the right products and imagery were served to the right markets.
The Build
The brief was straightforward — remove the reporting lag that was slowing the team down and replace it with something visual, accessible, and always current. What followed was a multi-year process of building, learning, and rebuilding that taught me more about data modelling than anything else in my career.
An external third party had previously configured the ODBC connection to our ERP system, but the table relationships and structure they left behind had some significant gaps. Before writing a single query, I took time away from marketing to sit down with our operations manager and develop a proper understanding of what the ERP data was actually saying and how it was structured. That investment paid off. I came away with a clear picture of the data model and was able to establish a working schema built around the following structure:
-
Two market datasets, each comprising a customer table and a sales table joined to an item table
-
Supporting reference tables for dealer targets and dates
With that foundation in place, the first version of the report was built and delivered. The sales team had visibility of performance across both markets for the first time, accounts had the numbers they needed without chasing anyone, and marketing had a live feed of sales data to inform campaign decisions. The gap between three previously siloed teams had been bridged.
People were using the report but now that they could see the possibilities, they wanted more. New calculated columns, additional DAX measures, and expanding requests from across the business began to take their toll. Refresh times became painfully slow, and the report was becoming increasingly difficult to maintain. It was working — but only just, and it wasn't going to scale. I reviewed the setup in full and made the decision to start again with efficiency as the primary design constraint.
The rebuild
The second version was built around three core changes:
1 — Query optimisation
Rather than pulling entire tables through the ODBC connection, I rewrote the data extraction using SQL queries that returned only the columns and rows the report actually needed. Filtering happened at the source, not in Power BI — dramatically reducing the volume of data being loaded on each refresh.
2 — Schema redesign
I removed the complex joins that had been doing heavy lifting inside the queries and replaced them with clean table relationships defined within Power BI's data model. This eliminated the need for a large number of custom columns and reduced the calculation load against the sales tables significantly.
3 — Primary keys and market consolidation
By creating consistent primary keys across the separate market tables, I was able to append them into a single unified dataset. This gave the report full cross-market visibility without duplicating logic or maintaining parallel versions of the same measures.
The result was a leaner, faster report that handled drill-downs and slicer interactions without hesitation — and a data model structured cleanly enough to accommodate future market expansions without requiring a rebuild.
Closing the loop with automation
The final piece was convincing the IT department to configure a gateway to the ERP system, enabling scheduled automated refreshes outside of business hours. The report now updates overnight so the team arrives each morning to current data — without anyone needing to touch it. It's the kind of invisible infrastructure that only gets noticed when it isn't there.
This report has since become the foundation for a broader suite of sales analytics work, extended further by connecting additional Excel-based datasets where needed.
More custom formulas were needed so we could display the information from our ERP, in a format that was friendly to all stakeholders.
A redacted snap shot of the top of the sales report. I know, the whole thing is redacted....
Schema was redesigned to have more tables holding unique information while also having combined similar tables from the different country ERPS.
What I Learned
Building this dashboard taught me the importance of querying efficiently. Early versions pulled more data than necessary, which put unnecessary load on internal systems. I learned to extract only what was needed and structure queries with that constraint in mind. I also learned how to automate report refreshing, removing the need for any manual intervention once the dashboard was live.
The schema went through three iterations as my understanding of data modelling deepened. I moved away from trying to do too much work inside queries — joining tables and engineering extra columns at the SQL layer — and instead built a cleaner model using individual tables with defined relationships in Power BI. This approach proved more efficient, easier to maintain, and simpler to build on top of.
I may have or may not have built more reports using this setup, that also connects to some Excel data sets...
Skills Demonstrated
Data Visualisation
ERP Data Modeling
Schema Structure
Hungry for more content?
SEO Strategy & Website Refresh
A two-part project combining a brand-level SEO strategy with a full website refresh onto a new CMS. Working alongside an external SEO expert, the goal was to identify and dominate organic search for key brand terms, then apply those learnings directly into the build of a refreshed website.