> For the complete documentation index, see [llms.txt](https://docs.powermonitor.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.powermonitor.com.br/en/technical-documentation/documentacao-tecnica/fluxo-de-scans.md).

# Scan Flow

How Power Monitor collects the Power BI and Microsoft Fabric inventory and metadata of each organization.

**Scans** are the mechanism through which Power Monitor collects and synchronizes the inventory and metadata of each organization's Power BI / Microsoft Fabric environment. They are separate from [continuous monitoring](/en/technical-documentation/documentacao-tecnica/monitoramento-continuo.md), which checks health and failures in short cycles.

## Overview

```
Schedule (daily) or request from an administrator (Mapping)
        │
        ▼
Persistent task queue (database)
        │
        ▼
Background processor ── one task at a time per organization
        │
        ▼
Scan type specification ──▶ Power BI / Fabric APIs
        │                       (customer's Service Principal)
        ▼
Mapping ▶ persistence ▶ reconciliation (deleted items)
```

* Tasks are stored in a **persistent queue in the database**: nothing is lost if the application restarts.
* The processor runs **at most one task per organization at a time**, so as not to overload the tenant's APIs, and records the start, end, progress, result, and errors of each run (visible in **Mapping › Scan Logs**).
* Stuck tasks are detected and reconciled automatically.

## Inventory scan types

| Type                                           | What it collects                                                             |
| ---------------------------------------------- | ---------------------------------------------------------------------------- |
| **Full**                                       | All workspaces (except personal ones) and all items, through the Scanner API |
| **Incremental**                                | Only the workspaces modified since the last scan                             |
| **Capacity**                                   | Fabric, Premium, and Embedded capacities and their administrators            |
| **Gateway**                                    | Data gateways                                                                |
| **Connection**                                 | Tenant connections (data sources)                                            |
| **App**                                        | Power BI apps and their reports                                              |
| **DatasetConnection** / **DataflowConnection** | Relationship between semantic models/dataflows and connections               |

In addition to these, there are specialized collections: model size (VertiPaq, through XMLA), report structure, model mapping, domains, activity events, capacity cost, per-item consumption metrics, Fabric item schedules, and Dataflows Gen1 runs.

## When scans run

| Moment                      | What happens                                                                                                                                                                                                                                                                        |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **End of installation**     | Scans of capacities, full inventory (of the chosen workspaces), gateways, connections, apps, and model × connection relationships                                                                                                                                                   |
| **Daily** (03:00 UTC)       | The same scans, automatically                                                                                                                                                                                                                                                       |
| **On demand**               | An administrator can start scans in **Mapping** (for example, the **Inventory** screen, for selected workspaces)                                                                                                                                                                    |
| **Specialized collections** | At their own times: model mapping (daily, 03:26 UTC), model size and report structure (daily, 01:16 and 01:50 UTC), domains (daily, 09:15 UTC), activity events (3 times a day: 04:22, 11:22, and 21:22 UTC), capacity cost (daily, 08:27 UTC), Dataflows Gen1 runs (every 2 hours) |

## Scanner API integration

The full scan uses the Power BI admin APIs (Scanner API):

1. **Lists the tenant's workspaces** (`GET /v1.0/myorg/admin/groups`, collaborative workspaces only). In the incremental scan, it uses `GET /v1.0/myorg/admin/workspaces/modified`.
2. Sends **batches of up to 100 workspaces** to `POST /v1.0/myorg/admin/workspaces/getInfo`, with the options `lineage`, `datasourceDetails`, `datasetSchema`, `datasetExpressions`, and `getArtifactUsers`.
3. **Tracks the status** of each batch (`GET .../admin/workspaces/scanStatus/{scanId}`) until completion.
4. **Gets the result** (`GET .../admin/workspaces/scanResult/{scanId}`) and maps each item type to the Power Monitor data model.

{% hint style="info" %}
The detailed metadata and DAX/M expression options depend on the tenant settings **Enhance admin APIs responses with detailed metadata** and **Enhance admin APIs responses with DAX and mashup expressions**. See [Prerequisites](/en/technical-documentation/instalacao/pre-requisitos.md).
{% endhint %}

## Important rules

* **Monitored workspaces:** the detailed scan of items ignores workspaces marked as not monitored. **New** workspaces, discovered by the scan itself, are collected in the same run; if the organization uses workspace selection (the default), they start as **not monitored**, staying out of the screens, alerts, and billing until an administrator includes them. Collecting is not the same as counting.
* **Scoped scan:** when an administrator chooses specific workspaces, they become monitored.
* **Deleted items:** in each cycle, the tenant inventory is compared with what is recorded. An item that disappears is **marked as deleted**, stops being counted on all screens and in billing, and starts being listed in **Governance › Operations › Deleted Artifacts**, with the date the deletion was detected.
* **Credentials:** calls use the organization's Service Principal (*client credentials* flow). Scans started manually by an administrator can use their delegated token, when available, with automatic fallback to the Service Principal.

## Related pages

* [Continuous Monitoring](/en/technical-documentation/documentacao-tecnica/monitoramento-continuo.md)
* [Data Model](/en/technical-documentation/documentacao-tecnica/modelo-de-dados.md)
* [Mapping](/en/power-monitor/mapeamento.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.powermonitor.com.br/en/technical-documentation/documentacao-tecnica/fluxo-de-scans.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.