Tag: Microsoft Fabric

Link to Fabric Just Got a UX Refresh and the Setup Friction Finally Drops

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published July 22, 2026

Microsoft announced a Link to Fabric UX refresh on July 20, 2026. Same underlying capability, cleaner setup path. If you have been putting off wiring Dataverse into Fabric because the old flow felt heavy for anyone who is not a data engineer, this is the week to revisit it.

I have set this thing up more times than I want to count. The capability was solid. The setup screens were where people bailed.

What the Link to Fabric UX refresh actually does

The refresh does not change what Link to Fabric is. You are still creating a managed replication of Dataverse tables into a Fabric workspace, landing them as Delta Parquet, and getting a SQL analytics endpoint on top. That plumbing is unchanged.

What changed is the front door. The old flow had too many decision points stacked in the wrong order. You picked a workspace, then got prompted about capacity assignment, then got a table picker that dumped every table in the environment on you, then had to reason about which relationships and long-term retention flags mattered. Makers who were building a Power App and just wanted their data in Fabric for a Copilot grounding source would get halfway in and close the tab.

The new flow collapses those decision points. Table selection is filtered and searchable by default. The workspace and capacity checks happen up front so you fail fast if permissions are wrong, instead of after you have already picked twelve tables. The confirmation screen actually tells you what will happen and roughly when.

It is a UX pass, not a feature drop. That is fine. The feature was already there.

Why the Link to Fabric UX refresh matters

Setup friction is one of those things that sounds like a small thing until you count how many projects it kills. I have watched teams decide against Fabric entirely because their first attempt at Link to Fabric turned into a two-week ticket exchange with the platform team over capacity and workspace roles. By the time it was sorted, someone had already built a Power BI dataflow against the Dataverse connector and moved on.

The other reason this matters is agents. I wrote about low-latency sync for Dataverse to Fabric going GA a while back. That closed the freshness gap. This closes the onboarding gap. If you are building agents that ground on Dataverse data through Fabric, both of those need to be easy. A capable data path that nobody sets up correctly is not a data path.

The people who benefit most here are not the data engineers. They already had the old flow memorised. It is the Power Platform makers who own a solution end to end and need analytics or agent grounding without filing a ticket to a separate team. That is a real audience, and it has been underserved on this specific path for a while. If you are thinking about how to evaluate what that grounding work actually costs versus what it returns, measuring useful work per dollar for your Power Platform AI agents is worth reading alongside this.

What you give up: nothing that I have found. The advanced controls are still there, they are just not in your face on step one.

What I would do with it this week

Three concrete things.

First, take a Dataverse environment where you previously gave up on Link to Fabric and try it again. Time the setup. If it went from a half-day of back and forth to under thirty minutes, that is your signal to standardise on this path for future work.

Second, wire a small agent against the resulting Fabric tables. Nothing fancy. A Copilot Studio agent with a knowledge source pointed at two or three tables you replicated. See how the answers feel with fresh data underneath. If you are still weighing whether to pull from SharePoint or Dataverse for that knowledge source, my SharePoint vs Dataverse as a Copilot Studio knowledge source comparison lays out the decision rule clearly. This is the loop I keep coming back to, and I have written more about how I think about grounding sources on my LinkedIn.

Third, revisit your Link to Fabric documentation and admin guardrails. The easier the setup gets, the more makers will do it themselves, which means capacity governance and workspace access reviews matter more, not less. Easier onboarding without governance turns into skill sprawl’s cousin: workspace sprawl.

The pattern here is familiar. Microsoft ships the capability, then eighteen months later ships the UX that makes people actually use the capability. That gap is where a lot of good features go to die. Glad this one did not.

Next up on my watchlist: whether the same treatment lands on the mirroring configuration screens.

Source: Announcing Link to Fabric UX refresh (Microsoft Power Platform Blog).

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

July 22, 2026
Low-Latency Sync for Dataverse to Fabric Hit GA and This Closes a Real Gap in Near Real-Time Reporting

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published June 21, 2026

Microsoft announced on June 9 that low-latency sync for Dataverse to Fabric is GA. If you have ever tried to build operational reporting or trigger Fabric pipelines off Dynamics 365 CE or F&O data, you know the old replication window was the bottleneck. Low-latency sync for Dataverse to Fabric GA cuts that window down to something close to real-time, and it ships without requiring you to rearchitect the Link to Fabric setup you already have.

I have been waiting for this one. The old 15 to 60 minute lag killed a lot of conversations before they started.

What it actually does under the hood

Link to Fabric has been around for a while. The original mechanism mirrored Dataverse tables into a Fabric OneLake shortcut using a delta sync that ran on a schedule. Reliable, cheap, fine for daily or hourly reporting. Useless for anything operational.

Low-latency sync changes the replication path. Instead of waiting for the batch interval, Dataverse pushes change events into the Fabric-side tables on a much tighter cadence. Same OneLake destination. Same Delta format. Same shortcut model. The difference is the lag between a row being written in Dataverse and that row being queryable in Fabric.

You enable it in the Link to Fabric configuration in the Power Platform admin center. Existing links can opt in. You do not have to tear down what you built. That is the part that made me actually want to test it this week instead of next quarter.

One thing worth flagging. Low-latency sync is for the CE and F&O tables you already mirror. It is not a streaming pipeline replacement. If you need event streaming with custom transformations mid-flight, you still want Eventstream or a proper Spark job. This is operational reporting territory, not Kafka territory.

Why this matters for reporting and agent scenarios

Two reasons I care about this.

First, operational dashboards. Anyone who has had the conversation with a sales ops lead about “can we see pipeline movement today” knows the answer was usually no, or we faked it with a direct Dataverse query that fell over at any real volume. With low-latency sync, the Fabric copy is fresh enough that a Power BI report on the OneLake shortcut actually reflects what is happening on the floor. That is a real shift in what you can promise.

Second, and this is the one I am more interested in, agent scenarios. I have written before about Dataverse as the agent data platform. Agents that need to reason over historical or cross-table data are better off hitting the Fabric copy than hammering Dataverse directly. The old lag meant any agent reading from Fabric was working with stale context. A sales agent answering “what is the status of this account” off 30 minute old data is useless. Off near real-time data, it is finally credible.

The latency question on agentic workflows is one I keep coming back to. It is not always the model that is slow. Often it is the data path behind the model. That same theme came up when I covered how Microsoft Build 2026 made Fabric and Azure Databases the foundation for agentic apps, and the low-latency sync GA feels like a direct follow-through on that direction.

What I would do with it this week

Three things, none of which require rearchitecting.

One. Pick an existing Link to Fabric setup on a non-prod environment and enable low-latency sync on it. Measure the actual end-to-end lag. Write a row in Dataverse. Time how long until it shows up in a Fabric notebook query. The marketing number and the real number for your tenant are usually different. I want to know my number.

Two. Take one Power BI report that currently runs on a scheduled Dataverse refresh and repoint it at the OneLake shortcut. See if the freshness story holds up when a business user pokes at it. This is the cheapest way to prove the value internally.

Three. Wire a Fabric data pipeline to trigger off a Dataverse table change through the low-latency path and have it call back into a Power Automate flow via a webhook. This is the pattern I want to validate for agent grounding scenarios. Whether the trigger-to-action loop is tight enough to feel real-time end to end is the actual question. If you are also thinking about how Dataverse surfaces structured knowledge to agents, the post on Microsoft shipping business skills in Dataverse is worth reading alongside this one. The Link to Fabric docs have the setup details.

I will probably write up what I find. Curious how this lands for anyone running heavy F&O workloads where the table volumes are an order of magnitude bigger than CE.

This is the kind of plumbing release that does not get a keynote slot but quietly unblocks a year of stalled conversations.

Source: Announcing Low-latency sync for Dataverse to Fabric in GA (Microsoft Power Platform Blog).

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

June 21, 2026
Microsoft Build 2026 Made Fabric and Azure Databases the Foundation for Agentic Apps and the Direction Is Clear

By Halilcan Soran · Power Platform & AI Agents · Senior Business Analyst at Visa · Published June 7, 2026

Microsoft just dropped its Build 2026 post on building agentic apps with Microsoft Fabric and Microsoft Databases, and the framing is the story. This is not a feature drop dressed up as a vision post. Microsoft is putting microsoft fabric agentic apps at the center of how it wants you to build, and the message is direct: the agent layer sits downstream of the data layer, and if your data is not consolidated, your agents will not be reliable.

I read this twice. The second pass is where the direction gets clear.

What it actually does

The post pulls Fabric and the Azure database family (SQL, Cosmos DB, PostgreSQL) into a single story as the substrate for agentic apps. The pitch is that you build agents that reason over the same governed data your analytics and operational apps already use, instead of stitching together vector stores, copies of production tables, and a separate semantic layer.

Concretely, the announcements lean on three moves. Fabric becomes the unified surface for structured, unstructured, and vector data with agent-ready APIs on top. The Azure database family gets tighter native integration with Fabric mirroring and AI capabilities baked into the engines, so embeddings, retrieval, and grounding live next to the data instead of in a sidecar service. And the developer story positions agents as first-class workloads, not bolt-ons. You point an agent at a Fabric workspace, it knows about the data contracts, the lineage, the policies.

The thing I keep coming back to: Microsoft is no longer treating the agent as the product. The data platform is the product. The agent is just one consumer of it.

Why the microsoft fabric agentic apps direction matters

This lines up with something I have been saying for a while. The hardest part of building an internal agent is not the model. It is getting the agent to behave like someone who actually works at your company. I wrote about that when Microsoft reframed Dataverse as the agent data platform, and Build 2026 extends the same logic up the stack. Dataverse handles the business policy and skills layer. Fabric handles the data and grounding layer. Both are now explicitly agent-aware.

If you are building on Power Platform and Azure and your data still lives across a SharePoint list, a legacy SQL box, a Synapse workspace nobody owns, and three Excel exports somebody emails on Tuesdays, this announcement is a warning shot. The friction is going to show up in a year. Your agents will hallucinate because grounding is inconsistent. Your latency will balloon because every retrieval crosses three services. Your governance story will not survive a single audit. I covered a related version of this problem when looking at Dataverse knowledge sources and agent feedback loops, and the data consolidation argument is the same one showing up here at the Fabric layer.

The trade-off is real. Consolidating on Fabric is not free. You give up some flexibility, you commit harder to the Microsoft stack, and you accept that Fabric capacity pricing is going to be a line item somebody fights about every quarter. But the alternative is building another silo, and silos are what kill agent reliability six months in.

The other piece I like: this framing kills the fantasy that you can buy your way into agentic apps by picking a better model. The model is not the bottleneck. The data contract is. Microsoft is finally saying that out loud.

What I would do with it this week

Three concrete things I want to poke at.

First, I would take one existing Copilot Studio agent that currently pulls from a Dataverse table and a SharePoint list, and rewire its grounding through a Fabric workspace with mirroring on the Dataverse side. Measure two things: retrieval latency end to end, and answer consistency across ten repeat questions. If Fabric mirroring holds up, that is a pattern I can reuse everywhere.

Second, I would build a tiny agent that reasons over a Cosmos DB collection using the native vector capabilities instead of pushing the data into a separate vector store. The question I want answered: does keeping embeddings next to the operational data actually reduce the drift problem, or does it just move the problem.

Third, I would map every current agent project against the question “is the data this agent depends on already in Fabric or on a clear path to it.” Anything that is not gets flagged. Not as a blocker, but as a known fragility. Before doing that mapping it is worth being honest about whether the agent even needs to be multi-agent in the first place — the single agent vs multi-agent decision shapes how complex your data dependencies get before you even write a line of grounding logic. I have learned the hard way that the architecture decisions you defer in month one are the ones that eat your weekends in month nine.

Microsoft just made the direction obvious. The teams that move on it now will be the ones not refactoring in 2027.

Source: Azure error (Azure Blog).

About the author: Halilcan Soran is a Senior Business Analyst at Visa working on process optimization with Power Platform, RPA, and agentic AI. He previously led a 15-person team at Thomson Reuters, where the Power Automate solutions he built started his automation career. More about Halilcan · LinkedIn

June 7, 2026