Building on Fabric data

Ask Claude for an app “using data from …” and the sprig data skill guides it through the right pattern:

1. Discover — Claude introspects your Fabric GraphQL endpoint’s schema (as you, with your permissions) so it never guesses field names.
2. Validate — it runs small real queries during the build to check shapes and filters.
3. Generate — the app’s frontend acquires a token for the signed-in viewer and queries Fabric directly from the browser. Paged grids fetch page-by-page; charts aggregate server-side where possible.

You need Run Queries and Mutations on the Fabric GraphQL API item (ask your data team), and the endpoint URI — copy it from the Fabric portal.

The rules the skill enforces

• No data in artifacts. Claude will refuse the “just put the data in the app” shortcut and explain why: your teammates should only ever see what their own permissions allow.
• Viewer identity, always. There are no service accounts to request and no secrets to manage.
• Semantic models are not yet supported — lakehouse/warehouse sources via GraphQL are; Power BI semantic models are on the roadmap.

Limits worth knowing

Fabric’s GraphQL API returns up to 100 items per page and caps a paged walk at 100,000 items (64 MB / 100 s per request). For dashboards this is rarely felt — filter server-side and aggregate rather than bulk-extract. Details: Limits.

“Why is my grid empty?”

Because the viewer’s own permissions returned nothing. That’s the product working: grant them data access through Fabric (your normal process) and the app fills in — no republish needed.