Compute is a shared pool you bought, not a charge per query. So refresh frequency, model size, storage mode, workspace count and who is allowed to publish are not independent choices. They are all decisions about how to spend one finite resource that every team in the organization draws from, which is why one badly built model can slow down reports belonging to people who have never heard of it.
We implement and remediate Fabric and Power BI for pharmaceutical, biotechnology, research and CRO organizations: lakehouse and warehouse design, pipelines and dataflows, semantic models that hold the measure definitions, governance that survives an export, and capacity designed deliberately rather than discovered through throttling. Our other Life Sciences pages argue that platform choice matters less than the definitional and governance work, and we stand by that. This page is for organizations that have made the choice and now need the implementation to be right.
Life Sciences organizations arrive at Fabric with a recognisable set of problems: clinical and commercial systems that do not speak to each other, reporting assembled by hand every month, three functions presenting different numbers for the same quarter, and leadership waiting on information that exists somewhere already. Fabric is a capable answer to the integration and delivery part of that. It is not an answer to the part that actually causes the symptoms, which is that nobody agreed what the measures mean, nobody owns them, and nothing distinguishes a report somebody can act on from a report somebody built for a question that no longer exists.
What is specific to this platform, and what most implementations learn late, is that its economics change how you design. Compute is purchased as capacity and shared, and the platform smooths and throttles under load rather than failing cleanly, which means the symptom of a problem usually appears in a different team from the cause. A report that got slow is frequently not a report problem. It is somebody else refreshing a very large model hourly for a decision that is made weekly. On a per-query platform that is a line on an invoice. Here it is everybody’s performance, which is why capacity planning in Fabric is a design discipline and not a procurement exercise.
Clinical and commercial systems were never connected
And the integration work is the visible part of a problem that is mostly definitional.
Reporting is assembled by hand and then defended by hand
Which is where the month goes.
Capacity is treated as a licence line
Until throttling arrives and the cause is in somebody else’s workspace.
Publishing is easy, so models multiplied
Nine semantic models, nine versions of the measure, all technically defensible.
Row-level security was configured and never tested at the export
Which is where it stops applying.
Real-time was requested for decisions made weekly
And the refresh schedule is now the largest consumer of the shared pool.
The migration moved the assets and kept the problems
Lifted dashboards and lifted logic arrive intact, including the parts that were wrong.
One estate is being asked to serve self-service and regulated reporting
Which fails in both directions at once.
Count your semantic models, then count the ones anybody owns. Inventory the semantic models in your tenant and, for each, establish who owns it, when it was last changed, how many reports depend on it, how many people used those reports in the last month, and whether its measure definitions match the certified ones. The common result is that a small number carry nearly all the real usage, a long tail carries none, and several in the middle are actively feeding decisions while having no owner at all. That middle group is the actual risk, and the inventory takes days rather than weeks.
Sizing appears third rather than last because in this platform it constrains everything after it. A capacity decision taken on a procurement timetable, before anybody has established what will refresh how often and how large the models will be, is a decision taken without the information it needs, and it will be revisited under pressure.
Step 1
Assess the decisions and the existing estate
Step 2
Architect the data layer around actual consumption
Step 3
Size capacity from a modelled workload
Step 4
Integrate sources with lineage intact
Step 5
Model the semantic layer deliberately
Step 6
Govern access, labels and the certified boundary
Step 7
Build reports for decisions, not for coverage
Step 8
Automate refresh, monitoring and reconciliation
Step 9
Deploy through controlled promotion
Step 10
Optimize capacity, cost and adoption continuously
Match every refresh schedule to the cadence of a decision. Go through the refresh schedules in your tenant and, for each, name the decision the data supports and how often that decision is actually made. Hourly refreshes feeding a weekly review are common, cost real capacity that somebody else needed, and nobody chose them deliberately. They accumulate because hourly felt safer at build time. This exercise typically releases meaningful capacity in a week of work, with no architectural change and no reduction in anything anybody uses.
Grouped by what the component is for. Most organizations need a subset, and the common error is adopting everything available because it is included rather than because a workload needs it.
Store and move
Fabric implementation and tenant, domain and workspace structure designed for governance
OneLake as the single storage layer, with a deliberate position on shortcuts and duplication
Lakehouse for engineering workloads and warehouse for structured relational consumption
Data Factory pipelines and Dataflows Gen2 for ingestion and transformation, with lineage retained
Notebooks and Spark where the transformation genuinely needs them, isolated from interactive load
Define
Semantic models treated as a governed interface, exposing approved measures and relationships rather than raw tables
One certified version of each measure, with variants explicitly named
DAX written for maintainability and performance, documented in business language
Power Query transformations kept thin, with heavy work pushed upstream
Storage mode chosen per workload across Import, DirectQuery and Direct Lake
Versioned hierarchies for product, territory, customer, site and organizational structures
Deliver
Power BI dashboards and enterprise reporting built around recurring decisions
Self-service analytics with a certified dataset boundary the platform enforces
Real-Time Intelligence where the decision is genuinely operational, not as a default
Embedded and distributed reporting, including Microsoft 365 surfaces
Paginated and operational reporting where a fixed format is the requirement
Extend and govern
Data science and predictive workloads in Fabric, with uncertainty reported honestly
AI-driven insight features used with their outputs checked against authorized datasets
Microsoft Purview for cataloguing, classification and lineage across the estate
Microsoft Entra ID for identity, with row-level security resolved per user at query time
Sensitivity labels applied so classification travels with data that leaves the platform
A Life Sciences organization putting clinical, commercial, manufacturing and finance data in one platform has done something useful and created a specific obligation. These domains carry different restrictions, and a shared storage layer makes the prohibited combinations technically easy. Domain and workspace structure is the first governance decision, not a tidiness exercise.
| Area | What gets built | The constraint that shapes it |
|---|---|---|
| Pharmaceutical R&D | Research portfolio, experiment and programme reporting | Scientific detail survives the model rather than being flattened for display |
| Biotechnology research | Assay, instrument and research data products | High-volume instrument data belongs in engineering workloads, not interactive models |
| Clinical trials | Enrolment, site performance and study operations reporting | Study blinding enforced per user at query time, and through export |
| CRO operations | Portfolio delivery, utilisation and milestone reporting | Sponsor separation enforced in the model, not by workspace convention |
| Clinical development | Programme planning, event rate and timeline reporting | Operational metrics only, with a boundary against submission analysis |
| Real-world evidence | Cohort, utilisation and outcome reporting | Permitted use and re-identification risk assessed before sources are linked |
| Pharmacovigilance | Case volume, workload and processing performance reporting | Operational reporting, not signal determination |
| Commercial analytics | Product, market and performance reporting | Syndicated data vendor permitted use terms enforced as access rules |
| Sales performance | Territory, region and target attainment reporting | Territory alignment held with effective dates so history can be restated |
| HCP engagement | Interaction, coverage and channel reporting | Professional data is personal data, and opt-outs must reach every view |
| Market access | Payer, formulary and coverage reporting | Coverage data aligned to the same geographies as the prescribing data |
| Manufacturing | Throughput, yield, deviation and process reporting | Where it informs a regulated decision, the controlled path applies |
| Quality operations | Complaint, deviation, CAPA and audit reporting | Quality records carry integrity obligations that reporting must not weaken |
| Supply chain and inventory | Demand, availability, channel inventory and service reporting | Shipment movement distinguished from consumption on the face of the report |
| Finance and executive reporting | Consolidated performance across the above | One certified set of measures, with reconciliation visible rather than assumed |
Most Fabric architecture errors come from applying one pattern uniformly. A high-volume instrument feed, a monthly finance consolidation and an interactive commercial dashboard have incompatible requirements, and the design that serves all three is the one that stops treating them the same.
| Decision | Choose this when | Watch for |
|---|---|---|
| Lakehouse | Engineering, semi-structured data, Spark transformation, large volumes | Interactive query expectations placed on an engineering workload |
| Warehouse | Structured relational consumption and familiar SQL access patterns | Being used as a general dumping ground because it is familiar |
| Import storage | Predictable fast interactive reporting on moderate volumes | Refresh cost and model size growing until the refresh is the problem |
| DirectQuery | Source must stay authoritative, or volume prohibits import | Every interaction becoming a query against a source that was not sized for it |
| Direct Lake | Large data in OneLake with low latency and no import step wanted | Suitability conditions, which are real and should be verified per workload |
| Dataflows Gen2 | Reusable, low-code transformation shared across consumers | Business logic drifting into dataflows where it is hard to govern |
| Notebooks and Spark | Transformation or data science the other options cannot do | Sharing a capacity with interactive reporting that then gets throttled |
Pick an important measure and count the places it is calculated. Take a figure leadership uses and trace every place its logic exists: the semantic model, a Dataflow, a Power Query step, a DAX measure in an individual report, an Excel file somebody maintains. If the answer is more than one, then changing the definition means finding and editing all of them, which in practice means they have already drifted. One place to calculate, one place to change, everything else inheriting. That is the whole of semantic modelling discipline, and it is the difference between a platform and a collection of reports.
The attempt to make one reporting estate serve both self-service analytics and regulated reporting fails in both directions. Apply controlled-path rigour to everything and the business builds in Excel instead. Apply self-service freedom to a report informing a regulated decision and the evidence to support it does not exist. The scope determination belongs to your quality and regulatory functions. What we build is two paths with a defined crossing point.
Frameworks where they apply
- GxP and GAMP 5 where reporting supports a regulated activity
- FDA 21 CFR Part 11 and EU Annex 11 for electronic records and signatures where applicable
- ALCOA plus as the standard records in scope are held to
- Scope, classification and validation strategy determined by your quality and regulatory functions
Privacy
- HIPAA where protected health information is processed
- GDPR and equivalent regimes, including professional data about healthcare professionals
- Sensitivity labels applied so classification travels with exported files
- Re-identification risk assessed before linking sources that were separately de-identified
Access
- Microsoft Entra ID groups driving access, with membership owned and reviewed
- Row-level security resolved per user at query time, tested with real user contexts
- Object and column-level restrictions where the sensitivity sits in a field
- Export, download and sharing rights treated as part of the access model
Traceability
- Microsoft Purview for catalogue, classification and lineage across the estate
- Lineage from a published figure back to the source system and load
- Audit trail over access, sharing, model changes and measure definition changes
- Controlled promotion with development, test and production genuinely separated
Fabric estates degrade along two axes at once. The data gets quietly wrong while every job reports success, and the capacity gets quietly consumed until month end becomes slow for everybody. Both are monitorable, both are usually unmonitored, and the second one is the reason the first one gets blamed on the platform.
| Failure | How it presents |
|---|---|
| A refresh succeeds on incomplete data | Totals are plausible, a source arrived short, and no job failed |
| A source schema changes | A column silently empties or maps to the wrong target and parsing still succeeds |
| Capacity is throttled at the peak | Reports slow for teams whose own workloads are small and well built |
| A model grows past its refresh window | The refresh starts overlapping the next one and the data is permanently stale |
| A measure is redefined in one report | Two versions circulate and both are defended as correct |
| A hierarchy changes without being versioned | Historical comparisons silently compare different things |
| Entra group membership drifts | Somebody retains access to rows their current role should not reach |
| A long-tail asset is still feeding a decision | An unowned model with no monitoring is quietly load-bearing |
Platform programmes get measured on what was built: workspaces, pipelines, reports, users onboarded. The outcomes that matter are the things that stop: the manual month-end assembly, the argument about whose number is right, the month-end slowdown, and the quarterly surprise about consumption.
| Outcome | How to tell |
|---|---|
| Data unified in practice | The recurring decision is made from one certified model rather than assembled files |
| Reporting accelerated | Month-end reporting no longer requires manual assembly or manual defence |
| Visibility improved | The people who need a figure can get it without asking somebody to produce it |
| Governance strengthened | Access tested through export, labels applied, lineage answerable, owners named |
| Self-service working | Analysts build on certified models because that is easier than starting over |
| Fabric cost optimized | Consumption known by workspace and item, schedule matched to decisions, no throttling at peak |
| Decisions faster | Each certified asset has an owner, a stated decision and evidence it is used for it |
We work with pharmaceutical, biotechnology, research and CRO organizations on Fabric and Power BI implementation and remediation: capacity sized from a modelled workload, storage mode chosen per workload, certified semantic models holding the measure definitions, access designed to hold at row level and through export, and a deliberate boundary between the self-service estate and the controlled path.
CaliberFocus implements and remediates Microsoft Fabric and Power BI for pharmaceutical, biotechnology, research and CRO organizations. We size capacity from a modelled workload, choose storage mode per workload, keep measure definitions in certified semantic models, and design access to hold at row level and through export, with a deliberate boundary between the self-service estate and the controlled path.
- Capacity, semantic models and governance designed as one thing
- Refresh schedules matched to the cadence of real decisions
- Row-level security tested as real users and through export
- Workspace structure that keeps clinical and commercial domains apart
Security & Compliance
