Microsoft Fabric Implementations — 5 Common Pitfalls and How to Avoid Them-NHS case study.

Microsoft Fabric promises a unified, end-to-end data platform that integrates storage, transformation, reporting, and AI capabilities under one roof. For the NHS, this is particularly valuable: multiple Trusts, ICSs, and community services can benefit from consistent reporting, streamlined submissions, and faster insights for patient care.

But as with any enterprise platform, success is not guaranteed. Many implementations stall or under-deliver because of missteps early in the journey.

Below are five common pitfalls in Fabric implementations, with NHS examples to show why they matter — and how you can avoid them:

1. Treating Fabric Like “Just Power BI on Steroids”

The pitfall: Many NHS teams view Fabric as simply a more powerful version of Power BI. They focus on building dashboards for urgent metrics but fail to plan for the broader data lifecycle — ingestion, transformation, real-time intelligence, governance, and advanced analytics.

NHS example: An Acute Trust rushing to deliver A&E 4-hour standard dashboards in Fabric, but without integrating source feeds from ED systems into OneLake. As a result, reporting remains manual and fragmented across sites.

How to avoid it:

• Position Fabric as a data platform, not just a reporting tool.

• Build a roadmap that includes national submissions (e.g., MHSDS, CDS, DM01), local reporting, and advanced modelling.

• Engage both BI and Data Engineering teams to avoid one-dimensional deployments.

  
  

2. Poor Workspace and Domain Design

The pitfall: NHS organisations often replicate their existing folder sprawl inside Fabric. Items are scattered across random workspaces, with no structure aligned to commissioning, acute, and community services.

NHS example: A CSU creates multiple “ad hoc” workspaces for each CCG request, leading to duplicate RTT datasets and no centralised source of truth. This makes ICB-wide reporting almost impossible.

How to avoid it:

• Adopt a Medallion Architecture workspace model (Bronze for raw, Silver for curated, Gold for trusted).

• Use domains and tags aligned with NHS structures:

  • BI Domain – corporate metrics, finance, workforce

  • Commissioning Domain – ICB population health, PCN data

  • Clinical Domain – acute & community service metrics

• Assign clear ownership using RACI (e.g., CSU data teams as custodians, Trust BI leads as contributors, ICB as consumers).

  
  

3. Ignoring Data Governance and Security from the Start

The pitfall: NHS organisations sometimes prioritise speed (meeting submission deadlines) over governance. Lineage, security, and data quality are sidelined until auditors or regulators raise concerns.

NHS example: A Trust builds Fabric pipelines for DM01 submissions but skips setting sensitivity labels or access controls. Months later, the ICO queries data handling, creating compliance risks.

How to avoid it:

• Apply role-based access control in OneLake aligned to NHS roles (e.g., analyst vs. clinician vs. manager).

• Use Purview for lineage — proving where figures like A&E attendances or referral volumes come from.

• Embed data quality rules for RTT or cancer metrics before data leaves the Trust, reducing rejected submissions.

  
  

4. Overcomplicating Data Ingestion and Transformation

The pitfall: Legacy ETL approaches are simply “lifted and shifted” into Fabric. NHS data teams overbuild complex pipelines for submissions that could be handled more simply with Dataflows or direct Lakehouse queries.

NHS example: An ICB builds heavy Data Factory pipelines to process GP appointment data, when a simple Dataflow would suffice. This increases refresh times, slows Power BI reports, and drives up capacity costs.

How to avoid it:

• Choose tools fit for purpose:

  • Dataflows Gen2 for lightweight reporting (e.g., Friends & Family Test).

  • Pipelines for orchestrated flows (e.g., CDS + SUS integration).

  • Notebooks for population health analytics or large-scale clinical coding transformations.

• Standardise storage using Delta Lake, optimised for large NHS datasets.

• Reuse common models for RTT pathways, OPEL status, and national KPI frameworks.

  
  

5. Neglecting Change Management and User Adoption

The pitfall: Fabric is rolled out as an “IT-led project” without bringing analysts, clinicians, or managers into the process. End users keep exporting data back to Excel or local Access databases.

NHS example: An ICB deploys Fabric with the aim of unifying data across acute and community providers. However, front-line analysts are not trained on semantic models, so they continue producing their own shadow reports, undermining trust in the central platform.

How to avoid it:

• Create an NHS Fabric Community of Practice, bringing together analysts across Trusts and ICBs.

• Train analysts on semantic models so they can self-serve and reduce duplicate reporting.

• Showcase early wins: for example, automating OPEL status reporting across multiple sites or delivering a live A&E demand dashboard.

• Establish feedback loops — clinicians and operational managers should shape how metrics are delivered, not just receive them.

  
  

📊 Pitfalls vs Best Practice Matrix

#	Common Pitfall	Real-World Consequence	Best Practice Response
1	Treating Fabric as “Power BI+”	Poor scalability, no central data model	View Fabric as an end-to-end platform; design for ingestion → transformation → reporting → AI
2	Poor workspace & domain design	Scattered data, unclear ownership	Use domain-aligned workspaces and Medallion architecture; assign clear RACI roles
3	Ignoring governance & security	Compliance breaches, low trust	Enable Purview, apply sensitivity labels, set RBAC & naming conventions
4	Overcomplicating data ingestion	High maintenance, slow refreshes	Adopt metadata-driven ingestion, use tools appropriately (Dataflow, Notebook, Pipeline)
5	Neglecting adoption & change mgmt	Low usage, project loses credibility	Build a Community of Practice, deliver training & quick wins to drive adoption

Key take away

For the NHS, Microsoft Fabric can be more than a data platform — it can be a catalyst for integrated care, faster national submissions, and better patient outcomes. But only if it is implemented with governance, scalability, and adoption in mind.

Avoiding the common pitfalls above ensures that Fabric does not become “just another IT system,” but instead a strategic enabler of the NHS data vision.