Forum Discussion
Power BI REST API returns PowerBIEntityNotFound for dataset with upstream
Hi,
What you’re hitting is not a permissions problem — it’s a limitation of the ExecuteQueries REST API with composite / upstream models.
Your Dataset B is PbixInCompositeMode and has upstreamDatasets (i.e., it’s a composite model that depends on another semantic model). In these scenarios, the ExecuteQueries REST endpoint can fail with “PowerBIEntityNotFound” even when the dataset exists and the caller is a workspace admin. This aligns with other reported cases where ExecuteQueries works for import models, but fails once a model becomes composite / DirectQuery over another semantic model.
A few important points:
The ExecuteQueries API has several limitations (and service principal scenarios have additional limitations such as RLS/SSO restrictions).
Composite models introduce extra security/lineage requirements (permissions across all participating models) and, in practice, REST ExecuteQueries is not reliable/unsupported for composite models even though XMLA works.
Recommended workarounds:
Query Dataset A instead (the upstream/import model) via ExecuteQueries, since that’s the part the REST API supports reliably.
Continue using the XMLA endpoint for Dataset B (since you confirmed it works) — XMLA is generally the more robust option for programmatic querying at scale.
If you must use REST ExecuteQueries, consider restructuring so Dataset B is not composite (i.e., avoid “dataset over dataset” / upstream dependency).
So, bottom line: Dataset B being a composite model with upstream datasets is the reason you’re getting PowerBIEntityNotFound via REST, while XMLA still succeeds.
Resolver IIHi,
What you’re hitting is not a permissions problem — it’s a limitation of the ExecuteQueries REST API with composite / upstream models.
Your Dataset B is PbixInCompositeMode and has upstreamDatasets (i.e., it’s a composite model that depends on another semantic model). In these scenarios, the ExecuteQueries REST endpoint can fail with “PowerBIEntityNotFound” even when the dataset exists and the caller is a workspace admin. This aligns with other reported cases where ExecuteQueries works for import models, but fails once a model becomes composite / DirectQuery over another semantic model.
A few important points:
The ExecuteQueries API has several limitations (and service principal scenarios have additional limitations such as RLS/SSO restrictions).
Composite models introduce extra security/lineage requirements (permissions across all participating models) and, in practice, REST ExecuteQueries is not reliable/unsupported for composite models even though XMLA works.
Recommended workarounds:
Query Dataset A instead (the upstream/import model) via ExecuteQueries, since that’s the part the REST API supports reliably.
Continue using the XMLA endpoint for Dataset B (since you confirmed it works) — XMLA is generally the more robust option for programmatic querying at scale.
If you must use REST ExecuteQueries, consider restructuring so Dataset B is not composite (i.e., avoid “dataset over dataset” / upstream dependency).
So, bottom line: Dataset B being a composite model with upstream datasets is the reason you’re getting PowerBIEntityNotFound via REST, while XMLA still succeeds.