Forum Discussion
Fabric Data Agent error user, help!
Per Microsoft's docs, Read access on the underlying Power BI semantic model should be enough for a user to work with a Fabric Data Agent — workspace access isn't a stated requirement. Since this user can already open the semantic model and its reports, and RLS is behaving correctly for them, I don't think we're looking at a basic model-permission gap.
So before touching anything permanent, here's the plan:
- Don't jump to granting Workspace Viewer. If we do add it and that resolves the issue, that's useful diagnostic signal — it'd point to an item-level access problem rather than a semantic-model one. But it should be a test, not a fix we leave in place.
- Reproduce it in Fabric directly first. Have the user ask a simple question there, outside of Copilot. If it fails in Fabric too, we know this isn't a Microsoft 365 Copilot-specific problem.
- Republish the Data Agent once we've confirmed the semantic model and agent config are up to date — just to rule out a stale publish.
- Pull the Data Agent's diagnostics/run details to see exactly where it's failing: auth, semantic model access, query generation, DAX execution, or RLS.
- Check Fabric capacity and service health around the exact time of failure, in case it's environmental rather than permissions-related.
- Log the details so we have them ready for Microsoft Support if needed: timestamp, user UPN, Data Agent ID, semantic model ID, the exact question asked, and any Request/Activity/Correlation ID.
Bottom line: the user's setup looks correct per Microsoft's documented model. The right next step is controlled diagnostic testing — not assuming Workspace Viewer is a required fix.
If this helps, ✓ Mark as Kudos | Help Other
Community ChampionHi Daan_vanRiel,
Based on Microsoft’s current documentation, I would not add Workspace Viewer as the next permanent fix.
Microsoft now states explicitly in the Fabric data agent sharing and permissions documentation that for a Power BI semantic model:
- Read permission is sufficient to query it through a Fabric data agent.
- Build permission is not required.
- Workspace membership is not required.
- RLS and CLS continue to apply.
So from what you described, the user should already have the minimum documented permission if they have Read on the semantic model and the published data agent has been shared with them.
I would therefore isolate where the failure actually occurs.
First, have the affected user open the published data agent directly in Fabric and ask exactly the same question that works for the developers.
If it fails there as well, I would focus on Fabric/data-source access rather than Microsoft 365 Copilot.
I would then verify that the agent does not use any additional data source beyond the semantic model.
Microsoft’s permission guidance says users need access not only to the data agent itself, but also to every underlying data source used by that agent.
So even if the semantic model permissions are correct, another Lakehouse, Warehouse, KQL database, ontology, or other connected source could still cause the query to fail.
I would check in this order:
- Confirm the user has access to the published version of the data agent.
- Confirm Read permission on the Power BI semantic model.
- Confirm the exact user is included correctly in the RLS role.
- Verify every other data source connected to the agent, if any.
- Test the same question directly in Fabric as that user.
- Only after that, test the same published agent in Microsoft 365 Copilot.
I would not treat Workspace Viewer or Build as required permissions here because that would conflict with Microsoft’s documented least-privilege model for Fabric data agents.
If temporarily granting Viewer makes the problem disappear, I would capture that as evidence for Microsoft Support rather than leaving the broader permission in place.
At that point I would provide Microsoft with:
- affected user UPN
- data agent item ID
- semantic model ID
- exact question that fails
- timestamp
- whether it fails in Fabric, Microsoft 365 Copilot, or both
- any correlation/session ID available
That should help determine whether this is a permission-resolution issue or a service-side problem.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.