A VP of sales operations at a mid-size manufacturer asks the new Sales Research Agent a simple question: “Are we tracking to quota this quarter across the East region?” The lakehouse holding quota, backlog, and actuals data has been live for months, built by the FP&A team specifically so questions like this could be answered without another spreadsheet cycle. The agent comes back with nothing useful, a vague answer built entirely from Dataverse pipeline data with no mention of quota or backlog at all. IT checks the lakehouse. The tables are there. The data is current. Nobody on the support call can explain why the agent can’t see what is plainly sitting in front of it.
The explanation, once you find it, is almost always the same: the person asking the question doesn’t have permission to the lakehouse item itself, only to the workspace it lives in, and the agent will not go around that. This is the part of a Sales Research Agent Fabric Lakehouse setup that trips up architects who have configured plenty of Power BI reports and Dataverse connections but have not internalized that this feature behaves nothing like either of those.
What a Sales Research Agent Fabric Lakehouse connection actually is
Dynamics 365 Sales’ Sales Research Agent reached general availability on April 30, 2026, after a public preview that started in mid-February, and it does something genuinely useful: it lets sales and revenue operations teams ask natural-language questions that span CRM pipeline data, finance and quota data sitting in a Microsoft Fabric lakehouse, and ad hoc files like a CSV export or a PDF board deck, all from one research canvas instead of three separate tools. The predefined insights it ships with cover attainment against quota, pipeline coverage relative to revenue goals, and variance between forecast, actuals, and invoiced results, which is exactly the kind of cross-system reconciliation that used to require a dedicated analyst and a Tuesday afternoon.
The part worth slowing down on is how the lakehouse connection is architected. It is not a data integration in the ETL sense, where an admin authorizes a service principal once and everyone downstream inherits access to a curated dataset. It is closer to a live pass-through: the agent authenticates to Fabric using the requesting user’s own Entra ID identity, via the same credentials they already use to sign into Dynamics 365. Whatever that person can see in the lakehouse through normal Fabric permissions is what the agent can see on their behalf, and nothing more. The agent never elevates privileges, and it never caches a broader view of the data than the user asking the question is entitled to.
The permission layers people forget
That single-sign-on design means two separate permission checks have to pass before a query against Fabric data will return anything at all. First, the user needs at least Viewer access at the workspace level, since Contributor and Admin also satisfy this but nothing less does. Second, and this is the one that catches people, workspace access alone does not imply access to a specific lakehouse item inside that workspace. Fabric enforces item-level permissions independently, so a user can be a workspace Viewer and still be denied at the lakehouse itself if nobody has explicitly granted them access to that item. Most Dataverse-oriented admins are used to security roles being the single gate; Fabric’s layered model means there are effectively two gates, and skipping a check on the second one is the most common reason a rollout stalls in the first week.
If the lakehouse data is organized through shortcuts pointing to another OneLake location or to Azure Data Lake Storage Gen2, there is a third layer: the user also needs read access on whatever the shortcut actually targets, since Fabric will not silently grant that just because the shortcut itself is visible. And if the organization has applied row-level or column-level security through a semantic model sitting in front of the lakehouse tables, that policy is enforced automatically for every query the agent runs. A regional sales director and a national VP asking the identical question through the agent can legitimately get different, both-correct answers, filtered by whatever RLS scope already applies to their account. That is a feature, not a bug, but it needs to be explained to end users before launch, or the first person who gets a narrower answer than a colleague will assume the tool is broken.
Getting the rollout right
The practical fix is to treat the Fabric connection as an access review project before it is a feature-enablement project. Before turning this on for a sales operations team or a broader analyst group, pull the actual list of who has workspace and item-level access to the relevant lakehouse, compare it against who is expected to use the agent, and close the gap deliberately rather than reactively. It is worth testing with a genuinely representative non-admin account rather than an admin’s own credentials, since an admin will almost always have blanket access that masks exactly the permission gaps a normal seller or ops analyst will hit.
Data quality inside the lakehouse matters just as much as access does, because the agent leans heavily on table names, column headers, and any descriptive metadata attached to them to figure out what a natural-language question is actually asking for. A table named tbl_fct_rev_q3 with undocumented columns will produce worse, less trustworthy answers than one named clearly with business-friendly column labels, even though the underlying numbers are identical. Where the schema can’t be renamed because other systems depend on it, the agent supports adding plain-language business context separately, and that extra half day of documentation work consistently pays for itself in answer quality once real users start asking open-ended questions instead of the handful you tested with.
One more subtlety worth building into a QA pass: currency handling is straightforward for native Dynamics 365 Sales data, since the agent uses the environment’s base currency automatically, but for lakehouse and uploaded-file data it has to infer currency from context. For a domestic single-currency organization this is a non-issue. For anyone with multi-entity or multi-currency operations feeding that lakehouse, it is worth deliberately testing a few currency-sensitive questions before general rollout rather than discovering the inference was wrong when a regional forecast number looks off by an exchange rate.
Budgeting for consumption, not just configuration
Access to the agent itself runs through a dedicated Sales Research Agent Reader security role, which is a clean, familiar Dataverse-style control and easy to scope correctly. What is less familiar is that every question run through the agent consumes Copilot Studio credits, so a rollout to an entire sales organization without any usage guardrails or monitoring can turn into a licensing conversation nobody budgeted for, especially once people realize they can ask it anything rather than just the handful of predefined insights it ships with. Treat the credit consumption model as part of the initial deployment plan, not an afterthought discovered on next quarter’s invoice.
None of this makes the Fabric integration a bad design. A pass-through model that never elevates permissions is the right security posture for a tool that reasons across finance and CRM data simultaneously, and the alternative, a broadly privileged service account with its own access to everything, would be a much worse outcome from a governance standpoint. But the security model only works as intended when the access review happens before launch. Organizations that have gone through this rollout carefully, treating the Fabric permission audit as a real workstream rather than a footnote, are the ones whose first week of feedback is about the quality of the answers rather than a flood of tickets asking why the agent can’t see obviously available data. That is the pattern we walk clients through at Routeget when a Sales Research Agent deployment is on the table: get the access model right first, and the rest of the rollout tends to go quietly.
#SalesResearchAgent #FabricLakehouse #Dynamics365Sales #DataGovernance #CopilotStudio #EnterpriseAI
No comment yet, add your voice below!