Halilcan Soran

Tag: Dataverse

  • Dataverse Just Got Knowledge Sources and Agent Feedback Loops and I Want to Wire These Up Now

    Dataverse Just Got Knowledge Sources and Agent Feedback Loops and I Want to Wire These Up Now

    Dataverse agent data platform new features including knowledge sources and feedback loops

    Microsoft published Dataverse Is Your Agent Data Platform: Here’s What’s New on May 5. I already wrote about the positioning shift, but the dataverse agent data platform new features in this post are the part I actually want to wire up this week. Knowledge sources you can attach to an agent. Agent feedback captured and stored back in Dataverse. Tighter coupling between business skills and the data model. That last bit is the one that changes my build order.

    What it actually does

    Three things stand out from the post.

    First, knowledge sources on Dataverse. You can now attach SharePoint sites, websites, files, and Dataverse tables as knowledge an agent can reason over, governed at the Dataverse level rather than configured per agent. The point is that knowledge becomes a managed artifact in the data platform, not a per-agent setting buried in Copilot Studio.

    Second, agent feedback stored in Dataverse. Thumbs up, thumbs down, and the conversation context land as rows you can query. That means feedback is not trapped in a separate analytics surface. You can write a flow on it. You can build a Power BI report on it. You can route a thumbs-down with a specific topic tag to the skill owner.

    Third, business skills tied to the data model. The business skills I wrote about when they shipped now sit closer to the tables they operate on. Skill ownership, policy versioning, and the data the skill reads from are governed in one place.

    For the official surface area, the Microsoft Learn docs are the right starting point once you have read the announcement.

    Why it matters

    I have built enough Copilot Studio agents to know where the pain actually sits, and it is never the model. It is the loop between what the agent does, what users think of what the agent did, and the policy owner who has to fix the thing that went wrong. That loop has been broken on Power Platform for a year.

    Feedback used to live in conversation transcripts you had to export. Knowledge used to be attached per agent, which meant the same SharePoint site got wired up four different ways by four different makers. Business logic lived in a 4000-token system prompt or a hardcoded Power Automate flow nobody could find six months later.

    Putting all three in Dataverse closes the loop. Feedback is a table. Knowledge is a managed artifact. Skills are versioned records with owners. You can finally write the query that says “show me every thumbs-down on the leave policy topic in the last 30 days, grouped by the skill that was invoked.” That query was not possible before. Now it is a view.

    The thing I am cautious about is the same thing I flagged with business skills. Sprawl. If five teams attach overlapping knowledge sources to overlapping skills with no naming convention, the agent will misroute silently and the feedback table will just tell you users are unhappy without telling you why. Governance has to come before deployment, not as a month-six cleanup. The multi-agent orchestration patterns that are now GA in Copilot Studio make this even more important to get right before you scale.

    What I would do with it this week

    I have a small internal agent that answers process questions. The plan for the next few evenings looks like this.

    Move knowledge out of the agent and into Dataverse. Right now the agent has three SharePoint sources wired up directly. I want one knowledge source registered in Dataverse, owned by the process owner, that any future agent on the same domain can reuse. That is the silo fix.

    Turn on feedback capture and build the report. Thumbs-down without a report is just noise. I want a Power BI page that shows feedback rate per topic, with a drill-through to the conversation. If I cannot see which skill was invoked when the user said no, I cannot improve anything.

    Pick one skill and version it properly. I am going to take the leave policy skill, rewrite it as a Dataverse business skill with an owner who is not me, and document the handoff. If the policy changes, the policy owner edits the skill. I do not get a ticket. That is the architectural shift I keep talking about, and it only works if I actually do it on something real. The error handling patterns that hold up in production become especially relevant once feedback loops are writing rows back into Dataverse and triggering flows downstream.

    None of this needs a new model. It needs the data platform to do its job, and it finally can.

    The interesting question now is what the second wave of agents looks like once knowledge and feedback stop being per-agent problems.

    This post was inspired by Dataverse Is Your Agent Data Platform: Here’s What’s New via Microsoft Power Platform Blog.

  • Microsoft Just Reframed Dataverse as the Agent Data Platform and the Update List Is Worth Reading

    Microsoft Just Reframed Dataverse as the Agent Data Platform and the Update List Is Worth Reading

    Dataverse agent data platform diagram showing knowledge sources, business skills, and Fabric integration

    Microsoft published a post on May 5 called Dataverse Is Your Agent Data Platform: Here’s What’s New. The framing is the part worth reading. Dataverse is no longer being sold as the database under your model-driven apps. It is being repositioned as the dataverse agent data platform, the layer that gives agents real business understanding instead of just rows and columns.

    That is a meaningful shift in how Microsoft wants you to think about the stack. I have been waiting for this framing to land properly.

    What it actually does

    The update bundles several things that were previously scattered across announcements into one coherent story.

    Knowledge sources let an agent ground itself in Dataverse tables, SharePoint sites, files, and external systems through a managed reference instead of a hand-rolled retrieval pipeline. The agent sees the data with its semantics: table relationships, choice columns, business rules. Not just a vector dump.

    Business skills are now first-class records in Dataverse. I wrote about this in Microsoft Just Shipped Business Skills in Dataverse. Skills move policy and process logic out of system prompts and into a managed, owned, versioned artifact. The May 5 post confirms this is the intended pattern, not an experiment.

    Deeper Fabric wiring means agents can reach analytical data through Dataverse without you stitching mirroring and shortcuts manually for every project. The semantic model carries through.

    Copilot Studio integration is tighter on the agent side. Connected agents in Copilot Studio can pick up Dataverse knowledge sources and skills as native primitives instead of you wiring them through custom connectors and Power Automate flows.

    None of these are individually new ideas. The point of the post is that they now line up as one platform story.

    Why it matters

    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. Org-specific policies, naming conventions, what counts as an active customer, which approval thresholds apply when. That tribal knowledge is where every agent project I have seen gets stuck.

    If that knowledge lives in a 4000-token system prompt, the agent degrades. If it lives in hardcoded Power Automate flows, nobody can find it six months later. If it lives in a Word document on someone’s OneDrive, it might as well not exist.

    The dataverse agent data platform framing says: put it in Dataverse as a typed, owned, versioned record, and let any agent on the stack consume it. That is an architectural decision, not a feature toggle. It changes who owns what. The policy owner updates the skill directly. The data steward owns the knowledge source. The agent builder stops guessing.

    The risk I keep flagging is skill sprawl. The moment multiple teams start writing skills with overlapping scopes, the agent starts misrouting silently. Governance has to come before deployment, not as a cleanup project in month six. Microsoft is shipping the platform. The org design is still on you. That same principle applies to Power Platform governance that does not kill adoption — the structural decisions made early determine whether the whole thing scales or stalls.

    I also want to see how this plays with multi-agent orchestration. I covered the patterns in multi-agent orchestration in Copilot Studio. If knowledge sources and skills become the shared substrate that connected agents draw from, the per-agent prompt size drops and routing gets more reliable. That is the part I find genuinely exciting.

    What I would do with it this week

    Three concrete things, in order.

    First, pick one existing agent that has a bloated system prompt. Anything past 2000 tokens. Pull out the policy chunks and rewrite them as business skills in Dataverse. Measure the prompt size before and after, and run your behavioral tests on both. You will see the consistency change in the edge cases.

    Second, take one knowledge source that today is glued together with a custom connector or a Power Automate flow doing retrieval. Replace it with a Dataverse knowledge source pointing at the same data. Compare the answers on questions that depend on relationships between tables. The native version handles joins the hand-rolled one fakes.

    Third, draft a one-page skill ownership matrix for your tenant before anyone writes a third skill. Who owns customer policy, who owns finance approvals, who owns HR routing. Boring document. Saves you from the sprawl that kills these projects.

    Read the Power Platform docs alongside the announcement. The framing finally matches what practitioners have been building toward. I am curious where it lands by the end of the quarter.

    This post was inspired by Dataverse Is Your Agent Data Platform: Here’s What’s New via Microsoft Power Platform Blog.

  • Microsoft Just Shipped Business Skills in Dataverse and This Is How You Teach Agents Your Org

    Microsoft Just Shipped Business Skills in Dataverse and This Is How You Teach Agents Your Org

    Dataverse business skills for agents announcement reaction

    Microsoft announced business skills in Dataverse on May 1, and this is the announcement I have been waiting for. Dataverse business skills for agents let you encode org processes, policies, and the tribal knowledge that lives in people’s heads as natural-language instructions. Agents discover them and follow them at runtime. No more cramming everything into a 4000-token system prompt and hoping the model remembers how your finance team handles approvals.

    I have been reading the docs since Friday. Here is my honest take.

    What business skills actually do

    A business skill is a Dataverse record. It contains a natural-language description of when the skill applies, what the agent should do, and what data or actions it can use. Agents query Dataverse at runtime, find the skills that match the user’s intent, and follow the instructions inside.

    The shape matters. You are not writing code. You are writing the kind of paragraph you would send to a new hire on day one. Things like: When someone asks about expense approvals over 5000 EUR, route to the regional finance lead, never to the team manager. The lookup table is in the Finance Approvers table. Always confirm the amount and the cost center before submitting.

    That description is stored, versioned, and indexed. Multiple agents can use the same skill. You update the skill once and every agent that discovers it picks up the new behavior. There is also a permission layer, so a skill can be scoped to a security role, a team, or an environment.

    Underneath, this is grounding. The agent does not memorize your org. It retrieves the relevant skill at runtime and follows it.

    Why this changes how you build internal agents

    The hardest part of deploying internal agents has never been the model. It has been getting the agent to behave like someone who actually works at your company. The model can reason. It cannot know that your procurement policy changed in March, or that the Madrid office handles APAC tickets on Wednesdays because of a coverage gap.

    Until now, that context lived in three bad places. System prompts that grew until they hit the context window and started degrading. Power Automate flows with hardcoded business logic that nobody could find six months later. Or worse, it lived nowhere and the agent guessed.

    I have written before that a focused 400-token instruction set produces more reliable behavior than a 4000-token one. Business skills make that practical. You stop stuffing the prompt and start composing skills. The agent picks the right ones for the job.

    The other thing this fixes is ownership. A business skill in Dataverse has an owner, an audit trail, and a lifecycle. When the policy changes, the policy owner updates the skill. They do not need to find the agent maker, file a ticket, or wait for a release. That is a real architectural shift, not a feature flag. If your org is still working out who owns what when policies change, Power Platform governance that does not kill adoption covers how to structure that before it becomes a cleanup problem.

    The risk I am watching: skill sprawl. If every team writes their own skills with overlapping scopes, the agent will face the same routing problem multi-agent setups face. Skill descriptions will start competing with each other and you will get silent misrouting. Governance has to come early, not as a cleanup project in month six.

    What I would do with it this week

    Pick one painful, well-bounded process. The kind where the answer is always it depends on who you ask. Approval routing is a good candidate. Onboarding checklists work too.

    Write three to five business skills that capture the rules. Keep each one short and specific. Connect them to a Copilot Studio agent that already has the right Dataverse and Power Automate connectors. Test with the messy questions, not the clean ones. Watch which skills get picked and which do not.

    The thing to measure is not whether the agent answers correctly. It is whether the right skill was selected for the right phrasing. If selection is unreliable, your skill descriptions are too similar or too vague. Rewrite them and try again. If you are also wiring up custom connectors to extend what the agent can reach, How to Build a Custom Connector for Copilot Studio Step by Step is worth keeping open in a tab.

    I will be writing more about this once I have run a real internal pilot. Early signals are good. In my experience, the patterns that survive contact with production are the ones where context is stored where it belongs, not where it was convenient at build time.

    This one belongs in Dataverse. Finally.

    This post was inspired by Introducing business skills: Teach agents how your organization works via Microsoft Power Platform Blog.

  • SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps

    SharePoint Lists Are Still the Best Backend for 80 Percent of Power Platform Apps

    SharePoint lists for power platform apps backend architecture decision

    There is a pattern I keep seeing on LinkedIn and in conversations with people at other organisations. A team starts a new Power Platform project, someone labels it ‘enterprise’, and suddenly the backend discussion jumps straight to Dataverse. No one questions it. Licensing gets justified in a spreadsheet, premium seats get budgeted, and six weeks later the solution is a list of 4000 records with a status column and three lookup fields. That is the moment I want to push back. For a big chunk of internal work, SharePoint lists for power platform apps are still the right call, and treating that choice as amateur hour is costing teams real time and money.

    Why SharePoint Lists Keep Getting Dismissed Unfairly

    The dismissal usually comes from two places. First, the word SharePoint carries baggage from the 2013 era that has nothing to do with what Lists actually is in 2026. Second, Dataverse gets sold as ‘the proper enterprise choice’ in every Microsoft deck, so picking anything else feels like admitting you cut corners.

    Neither of those is an engineering argument. They are vibes.

    In practice, a modern SharePoint list gives you a REST and Graph API, column-level validation, versioning, item-level permissions if you really need them, native integration with every Power Platform connector, and a UI that business users can actually open and fix when something looks off. You get Entra ID authentication for free. DLP policies cover it. The audit log flows into the same Purview tenant everything else does. For an internal request tracker, an onboarding checklist, a small approval queue, or a reference table that three flows read from, that is the whole job.

    The Workloads Where SharePoint Is Genuinely the Right Answer

    I am not arguing SharePoint wins everywhere. I am arguing it wins for a specific and very common shape of work.

    If the app is an internal tool, used by under a few hundred people, with a data volume that will never credibly pass 20 or 30 thousand items in any single list, and a schema that fits cleanly into flat records with a handful of choice and lookup fields, you are in SharePoint territory. Registrations, comms sign-offs, small approval workflows, asset inventories, internal request forms, training trackers, audit checklists. This is the bread and butter of Power Platform inside any large organisation.

    Building on a list for that kind of workload is faster in almost every dimension. You spin up the schema in minutes. Makers on your team can read and edit the data directly in the browser without a model-driven app wrapper. Your Power Automate flows use the standard SharePoint connector, which means no premium licence for the thousand people who happen to trigger a flow indirectly. That last point alone saves real budget. I have written before about how licensing shapes architecture choices in enterprise environments, and this is one of the clearest examples.

    The Real Limits You Need to Design Around

    SharePoint lists are not magic. They have hard edges, and you need to know them before you commit.

    The 5000 item view threshold is the one everyone quotes, and it is real, but it is a view and query limit, not a storage limit. A list can hold millions of items. You work around the threshold with indexed columns, filtered views, and delegable queries in Power Apps. If you are careful with your delegation, a list with 50,000 items performs fine for the usage patterns most internal apps actually have.

    Throttling is the other one. The SharePoint connector has its own limits, and if you are running a flow that hammers a list in an Apply to Each loop at full concurrency, you will get throttled. Same story I covered in the throttling post. Drop concurrency, batch your reads, and stop treating the list like a transactional database.

    Where SharePoint genuinely falls over is relational complexity. More than two or three lookups deep and you are building joins in Power Automate, which is painful to maintain. Row-level security beyond basic item permissions gets ugly fast. Calculated columns are limited. And if two users edit the same item in the same second, you can get conflicts the platform does not resolve gracefully. This is also where why Power Automate is still worth learning in 2026 becomes relevant — knowing how to structure flows around list limitations is a skill that pays off repeatedly.

    When to Actually Move to Dataverse

    Dataverse earns its licence cost when the workload has specific characteristics. Genuine relational depth with many-to-many relationships you actually traverse. Role-based security that needs to be enforced at the data layer, not the app layer. Business rules and calculated fields that are part of the data contract. Plugins, server-side logic, or integration with Dynamics. Auditing at the field level for compliance. Transactional guarantees where a failed write must roll back cleanly.

    If your project has three or more of those, Dataverse is the right choice and the licensing conversation is easy to win because the alternative is building those features yourself and maintaining them forever.

    If your project has none of them, and you are about to spend eight weeks justifying premium seats for 400 people so you can store a status column on 4000 records, stop. Build it on a list. Ship it next week. Spend the saved budget on something that actually needs it. And before you wire any intelligence layer into whatever you build, it is worth reading Adding Copilot to Your Power App Is Not the Same as Making It Smarter — the backend choice and the AI layer choice follow the same logic.

    The backend choice is an engineering decision, not a status symbol. I write more about these kinds of trade-offs on my LinkedIn if this is the kind of call you are wrestling with right now.

    Frequently Asked Questions

    When should I use SharePoint lists for Power Platform apps instead of Dataverse?

    SharePoint lists are a strong fit when your app is internal, used by fewer than a few hundred people, and will never exceed tens of thousands of items in a single list. Common examples include approval queues, request forms, training trackers, and asset inventories where a flat schema with a few lookup fields covers everything you need.

    Why does using SharePoint as a Power Platform backend save money on licensing?

    Power Automate flows that connect to SharePoint use the standard connector, which does not require a premium licence. In large organisations where thousands of users might trigger a flow indirectly, avoiding premium connector requirements can add up to significant budget savings compared to a Dataverse-backed solution.

    What are the security and governance features available with SharePoint lists?

    Modern SharePoint lists authenticate through Entra ID and are covered by your organisation’s DLP policies. Audit logs feed into the same Purview tenant as your other Microsoft 365 services, so governance and compliance requirements are met without additional configuration.

    How do I know if Dataverse is actually necessary for my Power Platform project?

    If a solution is genuinely enterprise in scale, involving complex relational data, high record volumes, or advanced role-based security requirements, Dataverse earns its place. However, if the data model is a few flat lists with simple lookups and the user base is a small internal team, reaching for Dataverse by default adds cost and complexity without a clear engineering benefit.