In this video I demo a Tableau sales dashboard built for a mockup of a retail database, Zhang’s Tea, simulated for this demo. One dashboard view driven by dynamic measures and action parameters that swap charts on click, reveal store level breakdowns on map hover, and surface weekly sales patterns without adding a single extra page.

📊 KEY RESULTS Sales dashboard with dynamic measures and action parameters that switch chart types on KPI click. Tooltip page design showing sales, quantity and customer count breakdown on symbol map hover.

🛠️ TECH STACK Tableau Desktop · LOD Expressions · Parameter Actions · Federated Excel Source · Symbol Maps

🔍 WHAT MAKES THIS DIFFERENT Most Tableau demos show one static page with numerous KPIs and charts. This build shows how a real multi-stakeholder report works with dynamic measures, action parameters and hover breakdown. Navigation and context replace page count. The insight surfaces with as little effort as possible from the person reading it.

Demo Data Notice: Dataset is based on a synthetic mockup of a Singapore retail tea business for portfolio demonstration purposes only.

What you’ll learn: 📥 Importing Excel data into Power BI 📊 Creating & formatting charts with purpose 🧩 How reports are structured conceptually, not just visually By the end, you won’t just have a dashboard. You’ll know how to think your way through building the next one.

In this video I demo a multi-page Power BI sales intelligence dashboard built for a mockup of a retail database, Zhang’s Tea, simulated for this demo. One data model and two dashboard views across laptop web version and mobile display version.

📊 KEY RESULTS

Sales Overview and Analysis dashboard on web and mobile with shared Year and District slicers. Tooltip page design showing city-level pie breakdown on map hover. Drill through product detail page.

🛠️ TECH STACK

Power BI Desktop · DAX · Power Query · Visual Maps · Decomposition Tree

🔍 WHAT MAKES THIS DIFFERENT

Most Power BI demos show one page with numerous KPIs and charts. This build shows how a real multi-stakeholder report works with storyboard page navigations, hover and drill-through details, and mobile screen design. Sales sees revenue vs target. Operations sees geographic volume. Each page answers a different business question from the same underlying model built in snowflake schema.

Demo Data Notice: Dataset is based on a synthetic mockup of a Singapore retail tea business for portfolio demonstration purposes only.

The connector you pick is not just a technical setting. It determines data latency, query performance, available features, and governance. The right way to think about it is this: what is the source, what path does the data take, and what does the report actually require. That framing drives every good connector decision.

Microsoft Fabric: The Modern Data Stack

Microsoft Fabric unifies what was previously a collection of separate Azure services into a single capacity licence with a shared storage layer called OneLake. This changes how data platforms are built in Microsoft environments.

Within Fabric, transformation happens through Dataflows Gen 2 for low-code ingestion, pipelines for orchestration, and notebooks for code-first engineering. Lakehouses store data in open Delta format on OneLake, which is built on Apache Parquet format underneath. Pure data science workloads favour Parquet precisely because column names, data types, and nullability are encoded within the file itself. This removes dependency on an external schema definition and makes the data self-describing. They serve as the central landing zone that multiple reports and semantic models can share. Warehouses provide a SQL endpoint for structured analytical workloads. KQL Databases handle real-time event streams.

In a mature Fabric setup, Power BI does not connect to source systems directly at report time. It connects to governed Lakehouse or Warehouse tables that Dataflows Gen 2, pipelines, or notebooks have already prepared. The Microsoft Fabric enterprise BI guidance is explicit on this point. The Get Data connector is the last step, not the first.

Databases: The Relational Workhorses

SQL Server, PostgreSQL, MySQL, Oracle, IBM Db2, and Amazon Redshift cover the most widely deployed data sources in enterprise environments. These are well-understood sources with predictable query behaviour. They support both Import and DirectQuery connection modes. For many organisations that have not yet moved to cloud-native architecture, these remain the primary layer feeding Power BI reports. Amazon Redshift supports DirectQuery but Import mode is preferred in production for performance reasons.

SAP HANA deserves specific mention. Enterprises still running SAP BW connect through the BW connector rather than HANA DirectQuery. The CDS view approach applies to modern S/4HANA deployments. In SAP environments, ABAP developers write CDS views, Core Data Services, directly on the HANA layer. A well-built CDS view handles joins, client filters, currency conversion, and authorisation checks. It presents a clean, business-ready data model without exposing raw SAP tables. Power BI connects to SAP HANA using DirectQuery, reading the CDS view live at query time. No import copy is maintained. The business logic stays in the SAP layer, maintained and versioned by the SAP team.

Pure DirectQuery on SAP HANA has known limits. Cross-source joins are not supported unless Composite Mode is used. Some time intelligence DAX functions do not push down to the HANA engine. High-cardinality columns can degrade query performance. The practical solution is Composite Mode: import small reference and dimension tables, keep large fact tables on DirectQuery against HANA. This unlocks cross-source joins and preserves data freshness where it matters while maintaining report performance.

Azure: Cloud-Native Sources

Azure SQL Database and Azure Synapse Analytics SQL are the primary cloud relational sources. Synapse handles large-scale analytical workloads. Synapse SQL pools remain widely deployed, but Fabric Warehouse is Microsoft’s strategic direction for cloud BI. Azure Data Lake Storage Gen2 connects to raw data zones. Azure Blob Storage covers unstructured file storage. Azure Cosmos DB supports NoSQL document workloads. Azure Data Explorer serves time-series and log analytics scenarios.

In hybrid environments where some workloads remain on-premise and others sit in Azure, these connectors bridge the two. Power BI developers are often the end consumers of Azure infrastructure that data engineering teams have already built. Knowing what sits behind a connector, and what it means for performance and data freshness, is what allows a practitioner to participate in architecture conversations meaningfully.

The DirectQuery Effect on Page Refresh

Every connector in Power BI delivers data through one of two modes. This is not a minor detail. It determines which features are available and how the report behaves in production.

Import mode copies a snapshot of source data into Power BI’s in-memory VertiPaq engine. Visuals render against this local copy. The data is only as current as the last scheduled refresh. Scheduled refresh is an Import mode concept. It runs on a defined interval in the Power BI Service and updates the snapshot.

DirectQuery sends a live query to the source system every time a visual renders or a filter is applied. There is no data copy. The data is always current. Scheduled refresh does not exist in DirectQuery because there is no snapshot to update. What you manage instead is query performance, caching strategy, and query reduction settings. Certain Power BI features including AI visuals and some DAX functions are only available in Import mode. Import mode unlocks the full Power BI feature set, while DirectQuery trades features for freshness.

The automatic page refresh feature visible in the Format Page panel follows this same rule. It only appears when the report uses DirectQuery. It allows the report to re-query the source on a set interval, independent of the manual refresh button. For Import mode reports, the option is simply not present. This is not a gap. It is the expected consequence of the connection mode chosen at design time.

For SAP HANA via CDS views, DirectQuery with Composite Mode is typically the right architecture. The HANA engine handles live queries efficiently and the business requires current data. For large historical datasets in a relational database or Fabric Warehouse, Import mode with a well-scheduled refresh delivers better report performance and broader feature support. The decision is made at design time. Not after the report is built.

Why Feature Engineering Comes First

Feature engineering creates new signal. Hyperparameter tuning optimises within existing signal. If the signal is weak, tuning cannot rescue it.

In this dataset, shipping mode was the top driver of late deliveries according to SHAP analysis. That column existed raw in the data. Other derived features required construction. Days since last shipment per customer-supplier pair. Rolling average delay by route over 30-day windows. A port congestion flag derived from external weather and holiday data. Each derived feature added measurable lift. Hyperparameter tuning alone could not have discovered these patterns.

In this project, feature engineering on domain variables produced the majority of the lift. Hyperparameter tuning added incremental gains on top of that foundation.

What the Full Pipeline Includes

The project uses standard MLOps tooling for reproducibility. ZenML handles pipeline orchestration. MLflow manages experiment tracking and the model registry. Validation uses a 37-month walk-forward backtest, not a cherry-picked holdout split. SHAP provides model explainability. Evidently monitors for data drift with rollback capability. A Streamlit executive dashboard surfaces the business cost of each wrong prediction, because a false negative in late delivery has a real dollar figure attached to it.

Most ML demos stop at the notebook. This one does not.

The code is available on GitHub.

When to Tune Anyway

Hyperparameter tuning is not useless. It adds value after feature engineering is exhausted. The mistake is doing tuning first, or only.

The Decision Order Matters

Build the right features first. Then tune. The decision order matters. Not after the model is deployed.