Overview Documentation Methodology Use Cases 🧪 Live Demo

Build Methodology

How the platform is delivered, source to dashboard. Each layer has one job, so failures are isolated, transforms are testable, and every reported number is traceable back to where it came from.

Map sources and define the grain

Start from the decisions leadership needs to make, then identify the systems that hold the data — ERP (Dynamics 365 Business Central), CRM, on-prem SQL Server, field spreadsheets, and external APIs. For each, agree the extract method, the refresh cadence, and the business grain (e.g. one row per order line) before any pipeline is built.

Ingest with Azure Data Factory

ADF pipelines extract each source incrementally where possible — change-tracking on databases, modified-date watermarks on the ERP/CRM, and file triggers for spreadsheets. Pipelines are parameterised and reusable, with retry, alerting, and run logging so a failed source is visible and re-runnable without touching the rest.

Land raw data in Snowflake — Bronze

Every source lands as-is in a Bronze schema, with load metadata (source, file/batch id, load timestamp). Keeping an immutable raw copy means transforms can be replayed and audited, and a bug in modelling never means re-pulling from the source systems.

Clean and conform — Silver (dbt)

dbt models standardise types, deduplicate, fix encodings, and conform shared entities — one customer, one product, one currency — across systems. dbt tests (not-null, unique, accepted values, relationships) run on every build, so data quality is enforced in code rather than discovered in a dashboard.

Shape business marts — Gold star schema

Gold models assemble a star schema: a central fact table (sales/transactions) at a clear grain, surrounded by conformed dimensions (date, product, customer, region, channel) with surrogate keys. This is the shape Power BI loves — simple, fast, and unambiguous to relate.

Build one governed Power BI semantic model

A single semantic model connects to the Gold marts, defines relationships and DAX measures once (revenue, margin %, YoY, running totals), applies row-level security by region/role, and becomes the only place metrics are defined. Every report — executive, finance, regional — reads from it, so the numbers always agree.

Operate, monitor, and document

Scheduled refresh, pipeline alerting, dbt documentation and lineage, and a clear data dictionary keep the platform trustworthy over time. New sources or measures are added without breaking existing reports because each layer is decoupled and tested.

Why medallion + a single semantic model?

The medallion split (Bronze/Silver/Gold) isolates concerns: ingestion problems stay in Bronze, quality logic stays in Silver, and business logic stays in Gold — each independently testable. Pairing that with one Power BI semantic model is what kills the "four different totals" problem: definitions live in exactly one place, so a metric means the same thing in every dashboard, and governance (security, certification, lineage) is applied once rather than per report.

📄 Documentation 💡 Use Cases 🧪 Open Live Demo →