## TL;DR
Delete the stale tile and pin a fresh tile from the report in its new workspace, because dashboard tiles keep a reference to the original report location. After a move, that reference points at content the dashboard can no longer resolve, and the tile shows the unavailable message while the report itself works. Repinning rebuilds the reference against the new location.

```text
activity unavailable
```

## Use this when
- Tiles show an unavailable message right after reports were moved to a new workspace.
- Opening the source report from the workspace works, but the dashboard tile does not.
- Only some tiles broke, matching the reports that were moved.

## Not for this skill when
- The source report itself errors when opened. Fix the report before repinning anything.
- The whole dashboard fails to load for all users. Check service or permission issues first.

## Steps
1. Click through one broken tile to its source and note whether it resolves to the old workspace location. Verify: the tile target is missing or points at the pre-move content
2. Open the report in its new workspace and confirm the visual the tile showed renders correctly there. Verify: the source visual displays current data in the new location
3. Delete the stale tile from the dashboard and pin the visual again from the relocated report, choosing the destination dashboard. Verify: the new tile appears and loads its visual without the unavailable message
4. Repeat the repin for every tile sourced from moved reports, checking each one loads. Verify: no tile on the dashboard still shows the unavailable state
5. If the move was part of a workspace upgrade, review dashboard sharing and alerts tied to the old tiles and reattach them to the new tiles. Verify: data alerts and sharing lists match the pre-move setup
6. Ask a viewer with standard access to open the dashboard and confirm the tiles render for a non-owner. Verify: a viewer sees data on all repinned tiles

## Why it happens
Tiles are references, not copies, and references do not survive content moves unless the platform migrates them. Because the report keeps working, teams often chase dataset refresh problems that do not exist. Checking the tile target first, and repinning as part of any planned workspace move, turns this into a two minute repair instead of an outage investigation.

Power BI dashboards are collections of pinned visuals that reference reports and datasets, often in other workspaces. Moving, copying or republishing a report creates a new content item, and existing tiles do not follow automatically. The dashboard therefore fails at the tile layer even though every source report opens normally. The same break appears after a workspace upgrade or a tenant migration that reissues content identifiers.

Field notes for Power BI specifically. The refresh history on each dataset, the gateway cluster view in the admin portal, and the workspace activity log together answer most incident questions without opening Desktop. The service and Desktop also diverge in behaviour often enough that a Desktop pass should never close a service incident. Test as a viewer in the browser, in the workspace the audience actually uses, because premium capacity, workspace version, and app publication state all change what the audience experiences compared with the author view.

Power BI estates benefit from an ownership rule that survives staff changes, datasets owned by a team alias or a service account pattern the tenant supports, with a named human deputy. A large share of refresh and security incidents trace back to content owned by someone who left, changed role, or lost a licence. Auditing dataset owners quarterly, and moving orphaned production content before it breaks, prevents the class of failure where the fix is trivial but nobody left on the team has the rights to apply it.
One more check worth making standard on this class of failure is a short written close out in the ticket or change record, naming the layer that was wrong, the exact setting or reference that changed, and the test that proved the fix. Dashboard incidents repeat across teams because the repair knowledge stays in the head of whoever fixed it first, and the next occurrence starts from the symptom again. Three sentences of record turn a one off repair into a searchable answer, and they cost less than any single step of the investigation that produced them. Teams that keep these notes find their second occurrence of the same failure takes minutes, not hours.
## Variants and edge cases
### Power BI tile activity unavailable after workspace move repin
The repin-focused variant naming the actual repair.
### Power BI dashboard tile broken report moved workspace
The move-triggered phrasing owners search after a migration.
### Power BI pinned visual unavailable source report works
The contrast phrasing where the report is healthy and the tile is not.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vqwsTzt3qxnd3ItrbZfXtw