Friday Fabric Facts#17
You Don’t Need “Full ML” to Get Value from Fabric’s Data Science Side
The Executive Insight
When “Data Science in Microsoft Fabric” comes up in a steering committee, the conversation usually drifts toward a program you’re not ready to fund: a dedicated ML practice, a new hiring plan, an MLOps roadmap, another platform-wide initiative with no clear ROI by Q4.
That’s not what most of your peers actually need.
What they need is one or two well-framed predictive problems sitting on top of the semantic and governance work they’ve already done in Fabric — and a loop that turns those predictions into different decisions in the dashboards their teams already use.
This issue is about that shift: from “Do we need to become an ML shop?” to “Where does lightweight modelling actually change decisions for us?”
What Fabric Actually Offers for Data Science
You know the components. The relevant point is how they fit together for BI-adjacent work:
Notebooks read directly from the same Lakehouse tables your reports already use — no export cycles, no separate feature store. MLflow gives you experiment tracking and a model registry without standing up a new platform. Predictions get written back to Lakehouse as columns or tables, then flow into your semantic model and into Power BI through the governance you already trust.
That last part is the one most teams underweight. The integration story isn’t about training — it’s about the round trip from curated data → model → prediction → existing report. Fabric is built for that loop. It is not built to replace Databricks, Vertex, or SageMaker for heavy ML, and it doesn’t need to.
The Real Blocker: Not Skills, but Questions
Your team can write Python. They can build a classification model. That’s not the constraint.
The constraint is focus. The typical pattern: leadership says “we should do AI,” the team opens a notebook, three weeks later there are experiments and plots but no line to a decision. The missing piece is a question that’s narrow, valuable, and operationally close to an existing report.
The most useful first questions look like this, and they should be drawn from your domain rather than the generic churn example everyone defaults to:
- Manufacturing: which work orders are likely to breach SLA this week, given current routing and labor availability?
- Financial services: which AR aging buckets are likely to roll forward 30 days, given customer-level payment history?
- Oil & gas: which wells are trending toward intervention based on production decline curves and the last 90 days of operating data?
Each of these has a clear owner, a clear action, and a clear feedback signal. That’s the qualifier, not the modelling technique.
Where Fabric Data Science Fits vs Where It Doesn’t
Where it fits: classification, regression, and ranking problems whose outputs land back in Power BI. Scheduled scoring jobs against Lakehouse data. Feature engineering on the same curated tables your semantic model uses. Anything where the win is “this dashboard now shows what’s likely to happen next, not just what already happened.”
Where it doesn’t: deep learning at scale, low-latency online inference, or specialized stacks already running on Databricks or a hyperscaler ML platform. If that’s where your team’s energy is, Fabric is a complement, not a replacement.
For most mid-market estates, the BI-adjacent lane is 80% of the value and 20% of the complexity. That’s the lane worth committing to first.
Copilot & Notebooks: Help, Not Autopilot
Copilot in notebooks is genuinely useful for skeleton code, exploratory queries, and explaining metric distributions. It compresses the time from “I have a question” to “I have a first experiment.”
It does not pick the right business problem, validate that your features are leak-free, or tell you whether the model is appropriate to deploy. Treat it as a productivity multiplier on a well-scoped problem, not a substitute for scoping.
Hope for Lean Teams: One Model, One Loop
The pattern that consistently works for teams without a dedicated data science function:
- Pick one decision that’s already BI-driven and has a clear owner — a CSM outreach list, a collections queue, a replenishment plan, a maintenance schedule.
- Frame it as a probability. “Likelihood this account churns in 60 days.” “Likelihood this invoice goes past 30.”
- Build on existing features. Use the same curated tables your reports use. If a feature isn’t in your gold layer yet, that’s a signal about your semantic model, not just your model.
- Train, track, register. Logistic regression or gradient boosting is usually enough. MLflow handles the traceability.
- Write predictions back to Lakehouse. A churn_score or breach_risk column on a gold table.
- Surface in an existing report. Not a new dashboard. The one the decision-owner already opens every morning.
- Measure whether decisions changed. Different accounts called, different invoices chased, different wells visited. That’s the only ROI signal that matters.
Run this loop two or three times across different domains before anyone needs to say the word “MLOps.”
Where I Fit In
For partners building a serious data science offering on top of an existing Fabric practice, and for CIOs, CDOs, and CTOs who want targeted modelling tied to revenue, risk, or efficiency — not an AI rebrand — my role is to help you pick the right first questions, design the loop, and make sure the outputs land back in the governance structures you already trust.
If your dashboards are ready to show what’s likely to happen next, that’s the conversation worth having.
Isaac Truong | Founder, Allston Yale
Enterprise-grade analytics for $50M–$100M SMBs
Power BI | Fabric | Azure | Data Strategy
Book a 20-min Fabric diagnostic →
Subscribe to get Friday Fabric Facts in your inbox (plus early access to templates)
LinkedIn: Connect with me for daily Fabric tips
Friday Fabric Facts #17: Originally Posted on LinkedIn, May 22, 2026
.