Turn Your Data Into Decisions — Not Just Dashboards.
Most organisations that have invested in Power BI are under-realising its value — not because the tool is inadequate, but because the difference between a Power BI report that executives open once and ignore and one they consult before every major decision is not design skill; it is analytical rigour. The data model that answers the right questions cleanly and quickly. The DAX measures that calculate the right business metrics rather than approximations that look correct until someone checks the numbers. The semantic layer that lets every business user answer their own questions without creating seventeen versions of the same inconsistent spreadsheet. The governance framework that ensures everyone is looking at the same definition of revenue, margin, or customer count rather than arguing about which report is correct. SourceMash delivers Power BI analytics engagements that address the complete data analytics stack — from data source connectivity and Power Query transformation through semantic model design, DAX development, report and dashboard engineering, Microsoft Fabric integration, governance, and the self-service analytics enablement that makes business users analytically self-sufficient without IT involvement for every question.
Power BI Is a Platform. We Deliver the Analytics Practice That Makes It Work.
Power BI is not a single product but a platform that spans the full modern analytics stack: Power Query for data ingestion and transformation, the Tabular semantic model (Analysis Services engine) for the in-memory analytical data model, DAX (Data Analysis Expressions) for calculated measures and the analytical logic that transforms raw data into business metrics, Power BI Desktop and Power BI Service for report authoring and publishing, Power BI Premium and Microsoft Fabric for enterprise-scale analytics with dedicated compute, and Power BI Embedded for integrating analytics into custom applications and portals. Each layer has its own best practices, its own failure modes, and its own professional expertise — and an organisation that has invested in Power BI licences without building capability across all of them gets the cost of enterprise BI without the analytical value.
SourceMash's Power BI practice covers the complete analytics delivery stack: BI strategy and governance, data architecture and source system connectivity, Power Query ETL development, semantic model design, DAX measure development, report and dashboard engineering, Microsoft Fabric implementation, self-service analytics enablement, embedded analytics, and the ongoing managed analytics service that keeps the BI estate accurate, performant, and aligned to the business's evolving questions.
Power BI Platform Coverage
Microsoft Certifications
BI Strategy, Architecture & Analytics Roadmap
Most Power BI deployments fail commercially not because Power BI is the wrong tool but because the deployment lacked a strategy — a clear definition of which business questions the analytics programme must answer, which data sources contain the information needed to answer them, who the consumers of the analytics are and what level of analytical sophistication each consumer group has, and how the analytics programme will be governed so that the answers it produces are trusted and consistently used. An analytics programme built without this strategy produces exactly what most organisations have already: a collection of reports that nobody agreed on, metrics that nobody can reconcile, and a growing library of dashboards that are opened once by the executive who commissioned them and then never opened again.
SourceMash's BI strategy engagement produces the architecture blueprint and implementation roadmap that gives the Power BI programme a foundation: the data architecture that determines where data is stored and transformed before reaching Power BI (Azure SQL Database, Azure Synapse, Microsoft Fabric Lakehouse, on-premise SQL Server), the semantic layer strategy (one shared semantic model vs. multiple domain-specific models vs. a thin report-layer approach), the governance framework that determines who can publish what to whom, and the prioritised report development roadmap that sequences development to deliver the highest-value analytical capabilities first.
Assessment Data sources, reports, quality audit
Blueprint Medallion / lakehouse / warehouse
Strategy Shared model vs. domain models
Framework Roles, access, certification policy
Roadmap 12-month prioritised workplan
Duration 3–6 weeks discovery + architecture
Semantic Data Modelling & Power Query Engineering
The Power BI semantic model is the most important determinant of report performance, DAX measure correctness, and the analytical flexibility available to report authors — more important than visual design, more important than the data refresh schedule, and far more important than the colour palette. A correctly structured semantic model (a star schema with clearly defined fact tables and dimension tables, correct relationship cardinality, appropriate storage modes for each table, and well-named columns and measures that reflect business terminology rather than database column names) makes every DAX measure simpler to write, every report faster to render, and every business user more self-sufficient. An incorrectly structured model (multiple many-to-many relationships, calculated columns where measures should be used, a flat table with all data in one place, or a denormalised fact table with hundreds of columns) produces slow reports, incorrect DAX calculations, and the analytical brittleness that breaks the moment a business user tries to ask a question the original developer did not anticipate.
Mode Import / DirectQuery / Composite
Convention Business terms — PascalCase enforced
Columns FK / tech columns hidden from view
Documentation ✔ Entity / measure dictionary
Star Schema Design
Star schema semantic model architecture — the gold standard for Power BI data modelling because the Analysis Services Tabular engine is optimised for it, DAX filter propagation works cleanly through single-direction relationships from dimension to fact tables, and the model's logical structure mirrors business analyst intuition (facts are measurements, dimensions are the context that measurements are viewed through). Fact table design: grain definition (what does one row represent?), additive vs. semi-additive vs. non-additive measures identification, foreign key relationships to each dimension. Dimension table design: surrogate key vs. natural key, slowly changing dimension handling, attribute hierarchies (Year > Quarter > Month > Date for the date dimension). Snowflake schema flattening into star schema where normalised source data requires denormalisation for optimal Power BI performance.
Date Table & Time Intelligence
Date table design for the intelligence infrastructure — the foundation of every time-based analysis in a Power BI model and the single most common source of errors in amateur Power BI implementations. A correct date table covers the full range of dates in the data with no gaps, is marked as the date table in the semantic model, has a unique date column of Date data type, and includes all the calendar attributes (Year, Quarter, Month Number, Month Name, Week Number, Day of Week, Is Weekday, Is Holiday, Financial Year, Financial Quarter) and business calendar attributes (Period, Fiscal Year) relevant to the organisation's reporting requirements. Time intelligence DAX measures built on top of this infrastructure: YTD, QTD, MTD, PY (Prior Year), YoY (Year-over-Year), YoY%, rolling averages, and the custom time intelligence calculations that standard DAX functions cannot produce for non-standard fiscal calendars.
Power Query ETL & M Language
Power Query data transformation using the M language — the ETL layer that shapes, cleans, and structures data from source systems before it enters the semantic model. Transformations: column type casting and error handling, text cleaning (trim, case normalisation, special character removal), pivot and unpivot operations, conditional columns, table merging and appending, custom column logic using M expressions, and the parameterised queries that enable the same transformation to be applied to multiple related tables without duplication. Performance-aware Power Query design: pushing transformation logic to the source database via query folding (letting the Power Query engine translate M expressions into native SQL that executes at the source) rather than loading raw data and transforming it in Power BI memory — critical for large datasets where query folding can reduce refresh times from hours to minutes.
Storage Modes & Performance
Storage mode optimisation for Power BI performance — the choice between Import (data loaded into Power BI's in-memory columnar store, fastest query performance, data is a snapshot at refresh time), DirectQuery (queries executed against the source database in real time, always current data, performance constrained by source database), and Composite (some tables in Import mode, some in DirectQuery, enabling near-real-time data for specific tables while maintaining fast query performance for historical data). Aggregations table design for DirectQuery models — creating a pre-aggregated Import-mode table that Power BI automatically uses for high-level summary queries while falling back to DirectQuery for detail queries, achieving near-Import-mode performance for the majority of user queries against a DirectQuery model.
Relationships & Filter Context
Relationship design that works correctly with DAX's filter context propagation — the most conceptually challenging aspect of Power BI modelling for analysts without a background in dimensional data modelling. Single-direction (active) relationships that propagate filters from dimension to fact tables, enabling DAX measures to automatically filter correctly regardless of which dimension attributes are used in report visuals. Inactive relationship management using USERELATIONSHIP() for role-playing dimensions (a single date dimension used for Order Date, Ship Date, and Due Date on the same fact table). Many-to-many relationship handling — identifying the bridge table pattern that resolves many-to-many relationships without the performance and filter context problems of direct Power BI many-to-many relationships.
Data Source Connectivity
Data source connectivity across the 100+ Power BI connector types: SQL Server, Azure SQL Database, Azure Synapse Analytics, and Microsoft Fabric for structured relational data; SharePoint Online Lists and Excel for business user-managed data; Salesforce, Dynamics 365, and SAP HANA via certified connectors; Google Analytics, Meta Ads Manager, and Google Ads for marketing analytics; REST API and OData connectors for custom system integration; and Dataflows Gen2 in Microsoft Fabric for centralised shared transformation logic that multiple semantic models and reports can consume without repeating the transformation logic. On-Premise Data Gateway configuration for scheduled refresh and DirectQuery connectivity to on-premise SQL Server, Oracle, SAP BW, and file systems.
DAX Development — Measures, KPIs & Advanced Analytics
DAX (Data Analysis Expressions) is the formula language that Powers the analytical intelligence of a Power BI semantic model — the language in which every business metric is defined, every time-period comparison is expressed, and every contextual calculation that changes based on what the report user selects is implemented. DAX is superficially similar to Excel formulas but operates on an entirely different evaluation model (filter context and row context propagated through the model's relationship graph rather than cell references) that produces results that feel intuitive when they are correct and deeply confusing when they are wrong. The most common Power BI failure mode — a report that produces numbers that look approximately right but are actually wrong in specific slice-and-dice combinations — is almost always a DAX error, usually caused by misunderstanding filter context propagation, using CALCULATE() incorrectly, or failing to account for the interaction between USERELATIONSHIP() and filter context.
KPIs Revenue, margin, churn, NPS etc.
Intelligence YTD, PY, YoY%, MTD, rolling avg
Functions Percentile, stddev, regression
Analysis Scenario parameters + DAX logic
Documentation ✔ Business definition + formula
Core Business KPI Measures
Business KPI DAX measure library covering the fundamental metrics each business unit requires: Finance (Revenue, Cost of Sales, Gross Profit, Gross Margin %, EBITDA, Net Profit, Budget vs. Actual Variance, Working Capital), Sales (Units Sold, Orders, Average Order Value, Revenue per Customer, Win Rate, Pipeline Value, Conversion Rate, Quota Attainment %), Operations (Throughput, Cycle Time, OEE, Defect Rate, On-Time Delivery, Lead Time), Customer (Customer Lifetime Value, Churn Rate, Net Promoter Score, Retention Rate, Days Sales Outstanding), and HR (Headcount, Attrition Rate, Revenue per Employee, Training Hours). Each measure documented with a business definition, calculation method, relevant filter context behaviour, and validation test cases.
Time Intelligence DAX
Time intelligence DAX measures covering the complete vocabulary of period-based analysis: YTD (Year-to-Date) using TOTALYTD() or CALCULATE([Measure], DATESYTD()), MTD and QTD equivalents, Prior Year (PY) using CALCULATE([Measure], SAMEPERIODLASTYEAR()), Year-over-Year (YoY) as [Measure] − [PY Measure], YoY% as DIVIDE([YoY], [PY Measure]), Rolling 3-Month Average using AVERAGEX(DATESINPERIOD()), and the custom fiscal year time intelligence that TOTALYTD() and SAMEPERIODLASTYEAR() cannot handle correctly without the year-end-date parameter and a correctly configured date table. Non-standard calendar handling: 4-4-5 retail calendar, ISO week calendar, and the custom fiscal period conventions that manufacturing and financial services organisations frequently use.
CALCULATE & Context Manipulation
Advanced DAX using CALCULATE() for filter context manipulation — the most powerful and most misused DAX function. CALCULATE(expression, filters) evaluates the expression in a modified filter context where the specified filters replace or add to the current filter context from the report's visual. Use cases: calculating a measure for a fixed period regardless of slicer selections (REMOVEFILTERS on the date table), computing a market share measure that holds the denominator at the total for the selected dimension (ALLSELECTED()), implementing currency conversion that applies the correct exchange rate for each transaction's date, and the complex multi-condition filtering that requires CALCULATE() with multiple filter arguments or CALCULATETABLE() for table-level filter manipulation. FILTER() vs. CALCULATE() performance: when CALCULATE() with column predicates is faster than FILTER() with row-by-row evaluation, and when FILTER() is necessary for row-level conditional logic.
Ranking, Top-N & Dynamic Analysis
Dynamic ranking and top-N DAX measures — RANKX(table, expression, value, order, ties) for ranking each row in a table by a measure value, enabling rank-based visual formatting (colour code the top 10 products by revenue contribution), rank-based filtering (show only the top 5 customers by spend), and rank trend analysis (has this product moved up or down in the ranking vs. last period?). Dynamic Top-N using what-if parameters: a TopN slicer allowing the user to select how many items to show in a ranked visual without requiring a separate report for each N value. Pareto analysis (cumulative revenue % by product): implementing the 80/20 analysis that shows which products, customers, or regions contribute 80% of revenue — using RANKX() combined with CALCULATE() with TOPN() for cumulative total calculation.
What-If Parameters & Scenario Analysis
What-if analysis using Power BI's Parameter table and DAX integration — enabling business users to model scenarios by adjusting parameters in the report rather than requesting new reports from the analyst. Use cases: price sensitivity analysis (if we increase price by X%, what is the revenue impact?), capacity planning (at what sales volume does the facility operate above 90% utilisation?), discount impact modelling (what is the GM% if we offer a 5% / 10% / 15% discount on this product line?), and the FX rate sensitivity analysis that treasury and finance teams use to model the P&L impact of exchange rate movements. Each what-if parameter implemented as a disconnected table with a DAX measure that incorporates the parameter value into the relevant calculations — enabling fully interactive scenario modelling without modifying the underlying data.
Advanced Analytics — Statistical & Predictive
Advanced DAX for statistical analysis and predictive indicators: moving average and exponential smoothing for trend smoothing on noisy data series; standard deviation and percentile calculations for distribution analysis (which customers are above the 75th percentile in spend?); cohort retention analysis DAX (what % of customers acquired in month M are still active in month M+N?); customer segmentation measures (RFM — Recency, Frequency, Monetary segmentation using SWITCH() with RANKX() on each dimension); contribution margin analysis with SWITCH(TRUE(), ...) for product category conditional logic; and the ABC classification DAX that segments inventory by revenue contribution for operations analytics. Integration with Python or R scripts in Power BI Desktop for advanced statistical models (forecasting, clustering, anomaly detection) where DAX's analytical capabilities are insufficient.
Reports, Dashboards & Executive Analytics
The visual layer of a Power BI deployment — the reports and dashboards that users interact with daily — is where the analytical investment becomes visible to the business. A well-designed Power BI report guides the user's attention to the information that is most relevant to their decision, makes anomalies and trends immediately visible without requiring the user to interpret raw data, and supports the natural analytical workflow of moving from summary (what happened?) to exception (where are the problems?) to detail (why did this happen?) without navigating to a different report for each level of depth. A poorly designed report overwhelms the user with data, uses chart types that are visually impressive but analytically misleading, and requires the user to understand the underlying data structure before they can interpret the numbers — producing the dashboard-opening-once-and-never-returning outcome that characterises most corporate BI deployments.
SourceMash's report design practice is grounded in information design principles: every visual element on the page must earn its space by answering a specific question; chart type selection is driven by the analytical question being asked rather than visual variety; colour is used to communicate information (red for unfavourable, green for favourable, grey for reference) rather than decoration; and the interaction design (slicers, drill-through, bookmarks, tooltips) supports the user's analytical workflow rather than impeding it.
Principles Information design — Tufte / Few
Alignment Custom theme JSON — corporate colours
Visuals AppSource certified + custom dev
Executive Dashboards & KPI Scorecards
Executive-level Power BI dashboards designed for 5-minute weekly review — a single page that shows the CEO or business unit head everything that requires their attention and nothing that does not. KPI scorecard design: traffic light indicators (P/G status) against budget and prior period for each key metric, sparklines showing the trend for each KPI, and exception callouts that highlight the specific metrics that are outside tolerance and require attention. The KPI card visual pattern: large metric value with directional indicator and comparison delta, formatted to communicate improvement or deterioration at a glance. Dashboard vs. Report distinction: Power BI dashboards (pinned tiles from multiple reports in Power BI Service, refreshed independently, visible on one screen without scrolling) for at-a-glance monitoring; Power BI Reports (multi-page, interactive, drill-through capable) for analytical investigation.
Interactive Analytics & Drill-Through
Interactive analytics design — enabling business users to move through analytical levels within a single report session rather than switching between multiple reports. Drill-through pages: right-clicking a product, customer, or region in a summary view opens a detail page filtered to that specific item — preserving filter context across the navigation. Drill-down hierarchy: clicking into a bar or column to decompose from year to quarter to month to day without requiring a slicer change. Bookmarks for guided analysis: pre-configured report states (this week's view, last month's view, regional view) that users can navigate between with a single click. Cross-filtering: selecting a segment of one visual automatically filters all other visuals on the page — enabling the instant slice-and-dice that makes Power BI analytically powerful for exploration rather than just presentation.
Custom Themes & Brand Design
Power BI custom theme development — JSON theme files that apply the organisation’s brand colour palette, typography (font family, font sizes for title, heading, and body text), default visual formatting (background colours, border styles, grid line colours, data label formatting), and the conditional formatting colour scales (diverging scales for variance analysis, sequential scales for density maps) consistently across all reports in the workspace. Custom theme design ensures that Power BI reports look like the organisation’s brand rather than default Power BI grey-and-blue, reducing the visual gap between Power BI and the organisation’s communication. Theme deployment via Power BI Service tenant-level theme distribution ensuring all new reports inherit the brand theme automatically without requiring manual theme application by each report author.
Custom Visuals & Advanced Visualisation
Custom visual development and certified AppSource visual deployment for analytical requirements that Power BI’s native visual library cannot address. Purpose-specific visuals: bullet charts for financial statement formatting (waterfall charts, variance columns, small multiples with consistent axis scales); Advanced Card visual for formatted KPI cards with conditional logic; Sankey diagrams for flow analysis; Timeline storyteller for event sequence analysis; and the HTML Content visual for highly formatted text and custom HTML rendering within Power BI. Custom visual development using the Power BI Custom Visual SDK (TypeScript, D3.js) for visuals with requirements that no AppSource visual meets — typically for organisations embedding Power BI in customer-facing applications where the visual must match the application’s design system precisely.
Report Performance Optimisation
Power BI report performance optimisation — reducing the visual render time from common 10–30 second range for poorly optimised reports to the sub-3-second target that makes Power BI feel like a responsive analytical tool rather than a slow database query. Performance Analyser in Power BI Desktop: capturing the DAX query, direct query, and other timings for each visual to identify which specific visuals are slow and whether the slowness is in the DAX evaluation, the data source query, or the visual rendering. Common performance fixes: replacing calculated columns with equivalent DAX measures (calculated columns are computed at refresh and stored in the model; measures are computed at query time with the current filter context — reducing model size), reducing unnecessary calculated columns reducing visual and page time significantly, reducing visual count per page (each visual is a separate DAX query; a page with 20 visuals generates 20 queries simultaneously), and converting high-cardinality text columns to integers for storage compression.
Mobile & Paginated Reports
Mobile layout design for Power BI reports — every Power BI report should have a phone layout configured that rearranges the desktop page’s visuals into a single-column scrollable layout optimised for thumb-based mobile interaction. Mobile layout considerations: card visuals and KPI cards work well at mobile scale; complex tables and matrices with many columns do not; slicer panels should be collapsed by default on mobile. Power BI Paginated Reports (RDL-based, PDL format) for print-optimised reports that cannot be produced in standard Power BI: formatted invoices, financial statements with precise column alignment and multi-page tables, pixel-perfect regulatory reports, and the detailed data exports that operational teams need in specific formatted layouts that standard Power BI reports cannot produce reliably across varying data volumes.
Industry-Specific Dashboard Portfolio
Pre-built dashboard templates and certified industry semantic models for rapid deployment across the sectors we serve most frequently.
- P&L by product, region, and customer segment with budget variance
- Loan portfolio quality dashboard — NPA ratio, provision coverage, vintage analysis
- Branch performance scorecard — deposits, disbursements, cross-sell ratio
- Fraud detection analytics — transaction anomaly rate, alert resolution SLA
- Regulatory reporting — Basel capital ratios, RBI compliance metrics
- Revenue by channel, category, brand, and geography with YoY trend
- Inventory analytics — stock turn, ageing, reorder point, carry cost
- Customer cohort analysis — LTV, retention, churn by acquisition cohort
- Digital funnel — sessions, add-to-cart, checkout, conversion by source
- Store performance scorecard — sales per sq. ft., basket size, staff productivity
- OEE (Overall Equipment Effectiveness) by line, shift, and SKU
- Quality analytics — defect rate, scrap cost, first-pass yield by process
- Supply chain — supplier OTD, lead time, inventory days, purchase price variance
- Production vs. plan — schedule adherence, output rate, changeover time
- Energy consumption per unit — sustainability and cost analytics
- Patient volume — OPD, IPD, ER by specialty, physician, and time
- Revenue cycle — billing, collections, AR ageing, denial rate by payer
- Bed occupancy, ALOS, readmission rate, and discharge analysis
- Clinical outcomes — complication rate, mortality index, LOS vs. DRG benchmark
- Operational KPI scorecard for hospital leadership
- Sales funnel — leads, opportunities, pipeline velocity, win rate by stage
- Revenue attainment vs. quota by rep, team, region, and product
- Customer acquisition cost, LTV, and payback period by channel
- Territory analysis — geographic revenue heatmap, whitespace identification
- Activity analytics — calls, meetings, demos vs. conversion correlation
- Headcount by department, grade, and location — trend and budget vs. actual
- Attrition analytics — voluntary vs. involuntary, by tenure, department, and reason
- Recruitment funnel — applications, interviews, offers, joiners by role and source
- Compensation benchmarking — pay equity analysis by gender and department
- Learning & development — training hours, completion rate, skills gap heatmap
Microsoft Fabric — Unified Data Analytics at Enterprise Scale
Microsoft Fabric is the most significant evolution in Microsoft's data and analytics platform since the introduction of Azure Synapse Analytics — a unified SaaS platform that integrates data engineering (Lakehouse, Data Factory pipelines), data warehousing (Fabric Warehouse), data science (Notebooks, ML models), real-time analytics (Eventhouse / KQL Database), and business intelligence (Power BI) into a single platform with a shared storage layer (OneLake) and a single governance model. The convergence eliminates the data movement, format conversion, and security boundary complexity that has historically made integrated analytics across these disciplines expensive and fragile — because all data in Fabric sits in OneLake (a single, unified, cloud-native data lake in the customer's Azure tenant) and all Fabric workloads read from and write to OneLake in the Delta Parquet format that makes data instantly available to any workload without ETL.
For organisations that have been building on Azure Data Factory, Azure Synapse Analytics, or Azure Data Lake Storage alongside Power BI, Fabric represents the convergence of these services onto a single, integrated platform with unified billing (Fabric Capacity Units replace individual Azure resource billing), simplified administration, and the Direct Lake connectivity to Power BI that eliminates the semantic model data refresh cycle for large datasets — enabling Power BI reports to query lakehouse data directly at near-Import-mode speed without copying data into the Power BI semantic model.
Fabric Lakehouse & Medallion Architecture
Microsoft Fabric Lakehouse implementation using the Medallion architecture (Bronze / Silver / Gold data layers) — the structural pattern that separates raw ingested data (Bronze — data as received from source systems, in original format), cleansed and validated data (Silver — data quality rules applied, data types corrected, duplicates removed, joined to reference data), and business-ready aggregated data (Gold — subject-area tables ready for consumption by Power BI semantic models, Fabric Warehouse queries, or data science notebooks). Lakehouse table management using Delta Lake format (versioned, ACID-compliant table format that supports time travel queries and incremental processing), PySpark notebooks for large-scale transformations, and Dataflows Gen2 for SQL and M-based transformations accessible to data analysts without Spark expertise.
Direct Lake & Power BI Integration
Direct Lake storage mode for Power BI semantic models in Microsoft Fabric — the breakthrough connectivity mode that eliminates the data refresh cycle that is the primary operational overhead of Import-mode Power BI. In Direct Lake, the Power BI semantic model reads Delta Parquet files from OneLake directly using column storage access, without copying data into Power BI's in-memory model. Performance is near-Import-mode (significantly faster than DirectQuery) because the column store format is the same format used by Power BI's in-memory engine, but data is always current because no refresh is required. Framing tables (the automatic optimisation that pre-loads frequently accessed data into memory for hot path queries) and fallback to DirectQuery for the rare queries that cannot be served from the framing cache. Direct Lake replaces the Import / DirectQuery / Composite mode decision for organisations that have adopted Microsoft Fabric as their data platform.
Fabric Pipelines & Data Engineering
Fabric Data Factory Pipelines for orchestrating data movement and transformation workflows — the Azure Data Factory-compatible pipeline engine within Fabric that connects data sources to OneLake. Pipeline activity types: Copy Data (moving data from SQL databases, APIs, cloud storage, and 90+ connectors to Lakehouse tables), Notebook (executing PySpark or Python transformations), Dataflow Gen2 (running Power Query transformations in the pipeline), Stored Procedure (executing SQL transformations in Fabric Warehouse or SQL databases), and Web Activity (calling REST APIs as part of data orchestration). Incremental loading patterns using watermark tables and change data capture to avoid full table loads on every pipeline run. Pipeline scheduling, trigger management, and monitoring with email notification on failure. Connection to Azure Key Vault for secure credential management across pipelines.
Fabric Warehouse & Synapse Migration
Fabric Warehouse (the T-SQL-queryable, cloud-native analytical warehouse within Fabric) for organisations that need SQL-based analytical workloads alongside Power BI — enabling data engineers and analysts who are proficient in T-SQL to build and query warehouse tables without requiring PySpark or other big data tooling. Fabric Warehouse vs. Lakehouse decision: Warehouse for SQL-first teams with structured analytical workloads; Lakehouse for big data engineering and data science workloads with mixed structured and unstructured data. Azure Synapse Analytics to Microsoft Fabric migration — migrating existing Synapse Dedicated SQL Pool and Synapse Pipelines workloads to Fabric Warehouse and Fabric Pipelines, taking advantage of Fabric's unified billing and simplified administration compared to the multi-resource Azure Synapse topology.
Self-Service Analytics & Business User Enablement
The highest-value outcome of a Power BI investment is not the set of reports that analysts build for business users — it is the analytical self-sufficiency of business users who can answer their own questions without submitting a request to the IT team or waiting for the analytics team to build a new report. Self-service analytics done correctly means every business user who needs to understand the data can explore it, slice it, and answer ad-hoc questions independently, within a governed framework that ensures they are all working from the same definitions of the business's key metrics and cannot accidentally publish misleading reports to the entire organisation. Done incorrectly, self-service analytics means an ungoverned proliferation of user-created reports with inconsistent metric definitions, no quality control, and no documentation — producing the spreadsheet chaos problem at Power BI scale.
Shared Semantic Layer Design
The shared semantic layer — a certified, governed Power BI semantic model that all self-service report authors use as their analytical foundation — is the infrastructure that enables self-service analytics without analytical chaos. A correctly designed shared semantic layer defines every business metric once (Revenue is not defined separately in the Finance report and the Sales report; there is one Revenue measure in one certified model that both reports use), exposes only the business-relevant attributes and measures (technical database columns, foreign keys, and intermediate calculations are hidden from the field list), uses business language for all names (the column is called "Product Category" not "PROD_CAT_CD"), and is documented with business definitions for every measure. Business users building their own reports from this foundation cannot produce inconsistent metric definitions because the definitions are in the model, not in each user's report.
Power BI Training Programmes
Structured Power BI training programmes tailored to three audience levels: Consumer training (2 hours) for users who need to interact with published reports — navigating the Power BI Service, using slicers and filters, drilling into details, subscribing to report snapshots, and sharing reports with colleagues. Analyst training (1 day) for users who will build reports from the certified semantic model — Power BI Desktop fundamentals, connecting to published semantic models, building visualisations, applying conditional formatting, and publishing reports to workspaces. Power User training (2 days) for the business super-users who will extend the semantic model with personal measures and calculated columns, build complex reports with advanced DAX measures, and mentor colleagues. All training delivered using the organisation's own data and report contexts for maximum relevance.
Q&A & Copilot for Power BI
Power BI Q&A natural language query configuration — enabling business users to type questions in plain English ("what were total sales last quarter by region?") and receive instant chart answers without requiring knowledge of which visual to use or which field to place where. Q&A synonym configuration: training the Q&A engine to recognise the organisation's specific terminology (if users say "revenue" and the measure is called "Net Sales", the synonym mapping ensures both terms produce the correct result). Q&A question curation: adding featured questions that surface the most analytically valuable query patterns to new users. Copilot for Power BI activation: AI-generated narrative summaries explaining what a report shows in plain language, Copilot-assisted DAX measure generation for power users (describing the calculation in words and Copilot generating the DAX syntax), and Copilot's report creation capability for generating initial report layouts from a semantic model.
Analytics Centre of Excellence (CoE)
Analytics Centre of Excellence design and establishment — the organisational structure and operating model that makes analytics self-service sustainable rather than a one-time deployment exercise. CoE components: Steering Committee (business stakeholders who prioritise the analytics roadmap and approve major investments), Analytics Leads (business unit representatives who understand both the business questions and the data, translate between business and IT), Power BI Champions (power users in each department who support colleagues and maintain departmental-level reports), and the central Analytics Team (data engineers and BI developers who maintain the shared semantic layer, develop complex reports, and build the data infrastructure). CoE operating model: how report requests are triaged (self-service vs. central development), how the shared model is extended and governed, and how the organisation's analytical capability grows over time.
Subscriptions, Alerts & Data-Driven Reports
Automated reporting distribution to stakeholders who need regular analytical updates without logging into Power BI Service daily. Power BI Subscriptions: scheduled email delivery of report snapshots to defined distribution lists at configured frequencies (daily, weekly, monthly) with the current state of slicers captured in the email image — ensuring every stakeholder receives the same consistent view at the same time. Data-driven subscriptions (Power BI Premium): parameterised report snapshots where each recipient receives a version of the report filtered to their relevant data (each regional manager receives the regional performance report filtered to their region — a single report subscription generates 20 personalised emails). Data alerts: notifications triggered when a KPI card value crosses a threshold (alert the sales director when monthly revenue drops below target).
Report Migration & Consolidation
Report portfolio migration and consolidation — for organisations migrating from legacy BI platforms (SSRS, Cognos, Business Objects, Tableau, Qlik) to Power BI, or consolidating an overgrown Power BI estate where 300 published reports have accumulated over time with significant duplication and inconsistency. Migration assessment: cataloguing all existing reports, identifying the actively used subset (usage analytics via Power BI's built-in usage metrics), classifying reports by analytical value and migration priority. SSRS to Power BI Paginated Reports migration for formatted pixel-perfect reports. Tableau to Power BI migration: workbook analysis, data source mapping, calculation translation (Tableau calculated fields to DAX), and visual redesign in Power BI. Report consolidation: identifying and eliminating duplicate reports measuring the same metrics differently, establishing the single authoritative version of each report category.
Power BI Embedded — Analytics Inside Your Applications
Power BI Embedded is the Azure service that enables Power BI reports, dashboards, and semantic models to be integrated directly into custom web applications, SaaS products, and portals — delivering the full Power BI analytics experience to users who authenticate through the application's identity system rather than a Microsoft 365 account. This is the architecture that enables an EdTech platform to show school administrators analytics about their students' progress inside the platform's admin portal without requiring each administrator to have a Power BI licence; a B2B SaaS company to embed customer-specific analytics in each customer's portal view with row-level security ensuring each customer sees only their data; or a manufacturing ERP to embed production analytics directly in the operations console where the relevant team is already working.
App-Owns-Data Embedding Architecture
Power BI Embedded App-Owns-Data implementation — the embedding model for customer-facing and B2B applications where users do not have Microsoft 365 accounts and authenticate through the application's own identity system. Architecture: a service principal authenticates to the Power BI REST API with client credentials, retrieves an embed token (a short-lived token granting access to the specific report with specific row-level security filter applied for the specific user), and the client-side JavaScript application uses the powerbi-client SDK and the embed token to render the report in an iframe-equivalent container. The application's backend is responsible for mapping the authenticated user to the correct RLS filter value before requesting the embed token — ensuring each user sees only the data they are authorised to see. Embed token refresh management: tokens expire after 1 hour and must be refreshed without interrupting the user's report interaction.
Dynamic Row-Level Security for Multi-Tenant
Row-level security (RLS) implementation for multi-tenant Power BI Embedded deployments — the mechanism that ensures each customer, user, or organisation sees only their own data in a shared Power BI report and semantic model. Dynamic RLS using USERNAME() DAX function: the embed token includes the user's identifier (customer_id, tenant_id, or user email) as the effective identity, and the RLS role filters the data model using USERPRINCIPALNAME() = USERNAME() where USERNAME() returns the effective identity from the token — automatically filtering every table in the model to only the rows that belong to the authenticated customer. Multi-dimension RLS for complex permission models: a user who should see data for multiple regions but not all regions, filtered at both the region level and the product category level simultaneously — implemented with multiple RLS filters combined using AND or dynamic table-based permission lookups.
Custom UI Integration & Theming
Power BI Embedded JavaScript SDK capabilities for deep application integration — going beyond iframe embedding to a fully integrated analytics experience that feels native to the host application. Programmatic filtering via the API: applying filters from the application UI (user selects a date range in the app date picker, the application calls the Power BI Embedded API to apply the equivalent filter to the embedded report, rather than showing the Power BI slicer). Cross-report highlighting: clicking a data point in the embedded report triggers an event in the host application that highlights the same entity in other parts of the application UI. Custom theming: applying CSS variables and the Power BI Embedded theming API to match the embedded report's visual styling to the host application's design system — hiding the Power BI chrome (page navigation, filters pane, bookmarks) where not needed. Report creation within the application: embedding the Power BI report authoring experience for users who should be able to build their own reports inside the application.
Embedded Capacity Planning & FinOps
Power BI Embedded capacity planning and cost optimisation — embedded analytics is billed via Azure Power BI Embedded A-SKU (hourly capacity billing based on size, from A1 at ~$700/month to A8 at ~$50,000/month) or Microsoft Fabric F-SKU (CU-based billing shared across all Fabric workloads). Capacity sizing: number of concurrent embedded users, report complexity (import vs DirectQuery vs Direct Lake), and peak usage patterns determine the minimum A-SKU that delivers acceptable report rendering performance. Pause/resume automation: Power BI Embedded A-SKU supports pause (no billing when paused) and resume via the Azure REST API — enabling automated pause during off-hours for B2B SaaS products where customers work business hours in specific time zones, reducing monthly cost by 40–60%. Per User (PPU) for internal applications where all users are Microsoft 365 licensed — a significantly lower cost option than A-SKU for internal embedded analytics deployments.
Power BI Governance, Security & Centre of Excellence
Power BI governance is the set of policies, processes, and controls that determine who can publish what data to whom, what data quality standards reports must meet before they are made available to business users, and how the Power BI estate is maintained and optimised over time. Without governance, Power BI deployments at scale produce the analytical equivalent of a messy filing cabinet: hundreds of reports that users cannot find, metrics that are calculated differently in different reports, sensitive financial data published to workspaces with overly broad access, and no reliable way to identify which reports are actively used and which are outdated. With governance, Power BI becomes the organisation's single source of analytical truth — a curated, certified, trusted estate of reports and semantic models that every business user relies on for data-driven decision-making.
Workspace Architecture & Deployment Pipelines
Power BI Workspace architecture design — the organisational structure of workspaces (containers for reports, semantic models, dataflows, and dashboards) that determines how content is organised, who can access it, and how it moves from development to production. Deployment workspace pattern: separate Development workspace (report authors build and test), a Test workspace (UAT by business stakeholders), and a Production workspace (published, certified reports available to all authorised consumers). Deployment Pipelines (CI/CD equivalent for Power BI content) that promote content from Development through Test to Production with automated comparison highlighting changes. Service principal authentication for automated deployment from the CI/CD pipeline. Workspace access management: who has Admin, Member, Contributor, and Viewer roles in each workspace, aligned to the organisation’s data access policy.
Endorsement & Certification Policy
Power BI content endorsement programme — the mechanism that communicates to business users which reports and semantic models are authoritative and trusted, and which are experimental or personal. Promoted status (yellow badge): content that is owned by a business owner, ready for broader consumption within the team. Certified status (blue badge): content that has passed the organisation’s certification criteria — data quality validation against known totals, business definition documentation for every measure, performance testing under load, RLS validation, and sign-off from business stakeholders responsible for the data domain. Certification criteria document: the explicit requirements that content must meet before the Power BI Admin (or delegated certifier) grants Certified status — creating a clear quality bar that distinguishes trusted from untrusted content.
Row-Level Security & Object-Level Security
Row-Level Security (RLS) implementation for Power BI semantic models containing sensitive or access-controlled data — restricting which rows of data each user can see in a report based on their identity. Static RLS: roles defined with fixed DAX filter expressions (e.g. [Region] = "North") for the simple case where each role corresponds to a fixed data partition. Dynamic RLS: a single role with a DAX filter that uses USERPRINCIPALNAME() to look up the authenticated user’s access permissions from a security mapping table — scaling to thousands of users without creating individual roles for each access combination. Object-Level Security (OLS): hiding specific tables or columns from users who should not see them (e.g. hiding salary columns from non-HR users while keeping the employee table visible for headcount analytics). RLS testing using the Power BI Desktop "View as Role" and Power BI Service "Test as user" capabilities.
Power BI Admin & Tenant Configuration
Power BI tenant settings hardening — the 100+ tenant-level settings in the Power BI Admin Portal that control what users can and cannot do in the organisation’s Power BI environment. Key settings to configure: Export and sharing (disable sharing with external users and export to CSV for sensitive workspaces, enable in non-sensitive ones), Data connection (allow or restrict which data sources non-admin users can connect to), Publish to web (disable for organisations where publishing is inappropriate), R and Python visuals (enable for data science use cases, disable for environments without security review), Workspace creation (restrict workspace creation to approved users rather than all users), and Dataflow export (control whether users can export Power Query transformations from dataflows). Sensitivity labels integration with Microsoft Purview: automatically applying sensitivity labels to Power BI reports and exports based on the classification of the data they contain.
Usage Analytics & Tenant Monitoring
Power BI tenant usage monitoring using the Power BI Scanner API and Activity Log — building a comprehensive inventory of all workspaces, reports, semantic models, and dashboards in the tenant, including metadata (owner, last modified date, size, refresh history), usage statistics (report views, unique viewers, average session duration), and data lineage (which reports use which semantic models, which semantic models connect to which data sources). Usage analytics enable informed decisions about: which reports have sufficient usage to justify ongoing maintenance, which reports have no users and can be deprecated, which semantic models are used as the foundation for many reports and therefore carry high impact change risk, and which users have access to sensitive workspaces who no longer require it. Custom usage analytics dashboard built on the tenant monitoring data for the Power BI CoE team.
Data Lineage & Impact Analysis
Data lineage visualisation and impact analysis — understanding the chain of dependencies from source system through transformations to the reports that business users consume, so that changes to upstream systems or shared semantic models can be assessed for downstream impact before they are made. Power BI Service’s native lineage view: the data lineage diagram showing the connection from data source through dataflows and semantic models to reports, enabling the analytics team to answer “If I change this semantic model’s date table, which of our 47 reports will be affected?”. Microsoft Purview data catalog integration: connecting Power BI’s lineage information with the broader enterprise data catalog for end-to-end lineage from source database columns through transformations to the specific DAX measures in the reports that executives use for decisions.
Data Source Connectivity — Systems We Connect
Power BI connects to 100+ data source types. Key systems we regularly integrate for enterprise clients:
The Business Impact of Done-Right Power BI.
Metrics from Power BI engagements across BFSI, retail, manufacturing, and healthcare clients — where the analytics investment translated into measurable decision-making improvement.
Latest from SourceMash
Perspectives, research, and practical guidance from our enterprise technology experts.
What Our Power BI Clients Say
We had invested in Power BI Premium licences 18 months before engaging SourceMash and had approximately 140 published reports — none of which the management team trusted, because the same metric (gross margin) was calculated differently in at least six of them. The CFO had stopped referring to Power BI and had gone back to the finance team's Excel model. SourceMash's discovery work identified 23 different definitions of gross margin across our report estate. They rebuilt the semantic model from scratch using a proper star schema with a single certified Gross Margin measure defined once — and then built the executive dashboard suite on top of that single model. The first time the CFO saw the new dashboard with numbers he could reconcile to the management accounts, he asked why it had taken us this long. The weekly management reporting cycle that previously took the finance team three days of manual data assembly now runs automatically overnight and is ready when leadership arrives on Monday morning. The board pack has been fully automated. We have retired 89 of the 140 reports — turns out most of them existed because nobody trusted the others.
We run 340 stores across four retail formats and had no single view of inventory performance across the chain — each format had its own Excel reports, each using its own definitions of stock turn, ageing, and days of cover, which made cross-format comparisons impossible. SourceMash built a Microsoft Fabric Lakehouse consolidating inventory data from our three different POS and ERP systems, a certified semantic model with standardised inventory metrics defined once and certified, and a self-service analytics programme that trained 200 merchandising and operations team members to build their own store and category level analyses from the certified data. The reduction in IT analytics requests was immediate — 87% within 3 months. More importantly, the merchandising team identified ₹2.4 crore of inventory carrying cost reduction opportunity in the first quarter of using the analytics — slow-moving lines that were not visible in the format-level aggregates were visible when the full chain inventory was in one place. That saving alone covered the entire programme cost in one quarter.
Our production team had no real-time visibility into OEE — Overall Equipment Effectiveness was calculated once a month by the production engineer manually pulling data from our MES system into Excel, which meant that by the time we saw that a line was performing at 61% OEE, it had been running at 61% for four weeks and the production loss had already happened. SourceMash connected our Siemens MES system and SAP production orders directly to Power BI via the on-premise gateway, built the OEE calculation in DAX (accounting for the difference between planned and unplanned downtime, the distinction between speed loss and quality loss, and the correct treatment of planned maintenance in availability calculation — none of which the standard OEE definition handles without careful model design), and deployed a real-time operations dashboard to the shopfloor TVs and the production manager's mobile. In 9 months, production loss identified and addressed through the dashboard analytics reduced by 18%. The scrap cost analytics identified three process steps responsible for 74% of our scrap cost — targeting those three steps has delivered ₹1.1 crore in annual scrap cost reduction and counting.