Failure while trying to import pbix or clone report

Hi gotters​ 

This would be because each report has got a semantic model, so 500 x 2 = 1000. I would highly recommend spreading your reports into different workspaces to allow for better governance and access controls.

No resolution and no clarity.
Just trying to create an MS support ticket

no, semantic models are in separate workspace and reports are connected to that. So internal count in the workspace is only 500. Btw the workspace report count was up to 700 at one point and it was fine. There has not been consistency about when this max is breached because its clearly about more than the visible artifacts.
Thats what i need clarity on

Hi gotters​,

The error name is the clue: it's the package count, not the item count. Every PBIX import creates a package record behind the scenes, and that is what the Imports API lists. A report created directly in the Service doesn't go through an import, which matches what you see: new reports in the Service work, but uploads and clones fail.

PBIX upload / clone -> creates an import package -> counted -> blocked
new report in Service -> no package             -> not counted -> works
deleted report       -> package can be left behind ("orphaned")

That also explains the inconsistency you noticed (700 reports was fine before). The limit depends on how many packages have built up over time, not how many reports are visible right now.

To size the problem, compare imports with reports that still exist:

Connect-PowerBIServiceAccount
$ws = "<workspace-id>"
$imports = (Invoke-PowerBIRestMethod -Method Get -Url "groups/$ws/imports" | ConvertFrom-Json).value
$reports = (Invoke-PowerBIRestMethod -Method Get -Url "groups/$ws/reports" | ConvertFrom-Json).value
$live = $reports.id

"imports: {0}  reports: {1}" -f $imports.Count, $reports.Count
$imports | Where-Object { -not ($_.reports.id | Where-Object { $live -contains $_ }) } |
  Select-Object id, name, importState, createdDateTime

There is no public API to delete an import record. So if the orphaned count is what pushes you over, the cleanup has to come from a Microsoft support ticket. Include the workspace ID and that list, since it makes the request concrete.

To stay unblocked in the meantime, publish in a way that doesn't create new packages:

overwrite instead of new: import with nameConflict=CreateOrOverwrite
  -> reuses the existing package for that report name
Fabric REST Items API: create the report from a PBIR definition
  -> POST /v1/workspaces/{id}/reports  (definition parts, no PBIX import)
Git integration / deployment pipelines
  -> items are synced from definitions
longer term: split the 500 reports by domain/audience into a few workspaces

So my overall approach would be:

list imports vs live reports -> quantify orphaned packages
-> support ticket to purge them (workspace id + list)
-> meanwhile publish via overwrite / PBIR definitions / Git
-> split the workspace before it reaches the limit again

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

Hi gotters​ 

We would like to inquire whether have you got the chance to check the solutions provided by other users in community to resolve the issue. We hope the information provided helps to clear the query. Should you have any further queries, kindly feel free to contact the Microsoft Fabric community.

Hi gotters​ 

We haven't heard from you on the last response and was just checking back to see if you have a resolution yet. And, if you have any further query do let us know.

Thank you.

Hi gotters​ 

Thanks for letting us know that you reach out to support team.
If you have solution handy please post it in the forum.