> 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/power-monitor/auditoria/auditoria-de-permissoes.md).
# Permissions Audit
Unified list of all permissions in the environment, workspaces, 21 Fabric/Power BI item types, gateways, connections, and Power Embedded, including access inherited from groups and workspaces.
The **Permissions Audit** brings together in a single list **all permissions on every object type** in your environment: workspaces, Fabric and Power BI items, gateways, connections, and Power Embedded reports. In addition to direct permissions, it **expands** inherited access: members of Microsoft Entra ID groups and items a user accesses because they have permission on the workspace where those items are.
**How to access:** *Audit › Permissions Audit*. Available to all profiles, within each user's workspace scope.
Unified list of permissions with the source of each access
## What it is for
* **Periodic access review** (recertification): export who has access to what for the owners to validate.
* **Principle of least privilege**: find who has *Admin* or *Member* unnecessarily, external accounts (guests) with write access, access granted individually instead of through a group.
* **Answering "who can see this report?"**: taking into account groups and workspace inheritance, not just direct permissions.
* **Employee offboarding**: list everything a person has access to before removing them.
{% hint style="info" %}
For the **aggregated** view (how many identities, concentration of administrators, external accounts with write access, environment matrix), use the [Permissions Dashboard](/en/power-monitor/dashboards/dashboard-de-permissoes.md), in the Dashboards menu. It uses the same data and filters as this screen.
{% endhint %}
## Features
### Group collection and Hide data
**What it is:** the action bar with the **View/manage collection →** link, the group cache status next to it (*Last updated: {date} by {user}* or *Groups never refreshed*; after a scheduled refresh, the user position shows *Automatic (scheduled)*), the **Hide data** button and the **Export** button.
**What it is for:** knowing whether the *Via group* expansion reflects who is currently in each Microsoft Entra ID group (before an access review or right after someone joined or left a group) and preparing the screen to be shared.
Action bar: group collection, Hide data and Export
**How to use:**
1. Read the status next to the link. If the cache is old or the groups were never refreshed, click **View/manage collection →**: it opens [Mapping › Inventory › Group Members](/en/power-monitor/mapeamento/membros-de-grupos.md), where the **Refresh groups** action lives (available to all profiles).
2. On **Group Members**, click **Refresh groups** and read the result message: success (*{N} group(s) refreshed, {M} failed.*), partial (some groups failed and stay outdated), failure to reach Microsoft Graph (no group was refreshed) or a missing application permission, in which case a tenant administrator needs to grant `GroupMember.Read.All` (or `Directory.Read.All`); no click fixes that.
3. Go back to the Permissions Audit: the status shows the new date and the list reflects the refreshed members.
4. Before sharing the screen, click **Hide data**: principals' names and e-mails (and the name of whoever refreshed the groups) are masked on screen and in exports. The button then shows **Show data**; the choice is saved in the browser and applies to the other screens with the button.
**How it works:** the members of each group with any permission are cached in Power Monitor and are refreshed automatically once a day (**Group members** scan, at around 07:35, Brasília time, in *Settings › Monitoring*) and on demand by the **Refresh groups** action. A failure in one group does not interrupt the others; the groups that failed keep their previous members. When the Power Embedded integration is configured, the manual **Refresh groups** action also reloads the Power Embedded permissions (the scheduled refresh only updates the group members). **Hide data** is a presentation convenience, not an access control.
{% hint style="info" %}
**Prerequisite:** your organization's registered application needs the **application** permission `GroupMember.Read.All` (or `Directory.Read.All`) in Microsoft Graph, with tenant administrator consent. See [Settings › Additional Permissions](/en/power-monitor/configuracoes/permissoes-adicionais.md).
{% endhint %}
### Filters
**What it is:** the bar with the **Workspace**, **Object Type**, **Source**, **Object** (*Search object...*), and **User** (*Search User*) filters, and the **Clear filters** button.
**What it is for:** answering questions such as "what does this person have access to?", "who can see this report?", or "who administers the gateways?".
Permissions Audit filters
**How to use:**
1. Click the filter field to open the panel.
2. Type in **Search...** and check the boxes of the desired options. In the **Object** and **User** filters, the search is done on the server and starts at 3 characters (before that, *Type to search* appears).
3. The field then shows *{N} selected*; the **X** next to the field deselects everything.
4. To remove all filters at once, click **Clear filters** (the number on the button indicates how many are active; with no active filters, the button is disabled).
| Filter | Type | Note |
| --------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| **Workspace** | Multi-select with search | When filtering by workspace, gateways, connections, and Power Embedded (which do not belong to workspaces) leave the list |
| **Object Type** | Multi-select | 25 types, in alphabetical order (full list in **Permission list**, below) |
| **Source** | Multi-select | Direct, Via Group, Via Workspace, Via Workspace + Group, Power Embedded |
| **Object** | Multi-select with server-side search | Real object names; at least 3 characters |
| **User** | Multi-select with server-side search | Email or name of the principal; at least 3 characters |
**How it works:** each filter change updates the list automatically and goes back to the first page.
### Access Source filter
**What it is:** the **Source** filter, which separates permissions by how the access was obtained.
**What it is for:** distinguishing access granted individually (which must be removed object by object) from access inherited from groups and workspaces (removed by taking the person out of the group or workspace).
Source filter options
**How to use:** open **Source** and check one or more options. The **Source** column of each row shows the detail:
| Source | Meaning |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **Direct** | Permission granted directly to the principal on that object |
| **Via group: {group}** | The user is a member of a group that has the permission; the row shows the member already expanded |
| **Via workspace permission** | Item accessed because the principal has direct permission on the workspace where the item is |
| **Via workspace permission (group: {group})** | Item accessed because a group the user is a member of has permission on the workspace |
| **Power Embedded** | Report permission coming from the Power Embedded permissions report |
### Permission list
**What it is:** the table with one access path per row, 20 rows per page by default. The footer has the **Items per page** selector (10, 25, 50 or 100) and the page navigation.
**What it is for:** seeing who (principal) has which access level on which object, and through which path.
| Column | Content |
| ------------------ | ----------------------------------------------------------------------------------------------------------- |
| **Object Type** | Badge with icon and type (Workspace, Report, Dataset, Lakehouse, Gateway, Connection, Power Embedded, etc.) |
| **Workspace** | Workspace of the object (empty for gateways, connections, and Power Embedded) |
| **Object** | Object name |
| **Principal** | User, group, Service Principal, or the entire tenant that has the permission (name and email) |
| **Principal Type** | Identity type (user, group, application, etc.) |
| **Access Right** | Permission granted (for example, Admin, Member, Contributor, Viewer, Read, Write, Owner) |
| **Source** | How the access was obtained (see the Source filter) |
**Object types covered:** **Workspaces**, **Gateways**, **Connections**, **Power Embedded**, and 21 item types: Reports, Datasets (semantic models), Dashboards, Dataflows, SQL Databases, Warehouses, Copy Jobs, Data Pipelines, Environments, Eventstreams, Lakehouses, Mirrored Databases, ML Models, Notebooks, Variable Libraries, App Backends, Graph Models, dbt Jobs, Data Agents, ML Experiments, and Ontologies.
**How it works:** the list has no column sorting and no per-row detail; use the pagination in the footer. On narrow screens, each row becomes a card with the name of each column next to the value. The same person can appear several times on the same object: one row for each access path.
### Export
**What it is:** the **Export** button, in the action bar, with the **CSV** and **JSON** options.
**What it is for:** sending the list to the people responsible for access recertification and keeping evidence of the review.
**How to use:**
1. Apply the desired filters.
2. Click **Export** and choose **CSV** or **JSON**.
3. The download starts automatically, with up to 50,000 rows. If something goes wrong, *Failed to export data.* appears.
With **Hide data** on, the identity columns (principal name and e-mail) are masked in the file; if the file cannot be masked, the screen warns *Could not mask the exported file. Show the data again or try once more.* instead of downloading exposed data.
## Rules and behavior
* **Source of permissions.** Workspace and item permissions come from the Power BI/Fabric inventory scans; gateway and connection permissions, from the gateway and connection scans; Power Embedded permissions, from the Power Embedded permissions report, loaded automatically twice a day (around 07:23 and 13:23, Brasília time, UTC-3) and also when someone clicks **Refresh groups** in *Group Members*.
* **Group expansion.** The members of each group are cached in Power Monitor and are updated automatically once a day (at around 07:35, Brasília time, if the **Group members** scan is on) and when someone clicks **Refresh groups** on the [Group Members](/en/power-monitor/mapeamento/membros-de-grupos.md) screen. The failure of one group does not interrupt the others: the result reports how many groups were refreshed and how many failed, and the ones that failed keep the previous members.
* **Microsoft Graph prerequisite.** To expand groups, your organization's registered application must have the **application** permission `GroupMember.Read.All` (or `Directory.Read.All`) in Microsoft Entra ID, with tenant admin consent. Without it, the screen warns that no click will solve the problem: the permission must be granted in Entra ID.
* **Workspace inheritance.** A permission on the workspace generates one row for each item in the workspace, for the same principal (and for each member, when the principal is a group). Duplicate rows are consolidated.
* **Workspace scope.** You see only the permissions of the workspaces you can view.
## Step by step: common scenarios
All the steps start from *Audit › Permissions Audit* and are available to any profile, always within the workspaces in your scope. If an administrator blocked this page for your user in [Users](/en/power-monitor/usuarios.md), it disappears from the menu and direct access through the address leads to the **Not allowed** screen. If the screen itself displays **Access Denied**, the server refused the query for your user: talk to an administrator.
### How to list everything a person has access to
Use it in access reviews and in employee offboarding.
{% stepper %}
{% step %}
### Refresh the groups
Check the date next to **View/manage collection →**; if the cache is old, open the screen, click **Refresh groups** and come back.
{% endstep %}
{% step %}
### Filter the user
In the **User** filter, type at least 3 characters of the email or name and select the person.
{% endstep %}
{% step %}
### Analyze the source
Use the **Source** filter to separate **Direct** access (which must be removed object by object) from access inherited **Via Group**, **Via Workspace**, and **Via Workspace + Group** (removed by taking the person out of the group or workspace).
{% endstep %}
{% step %}
### Export
Use **Export › CSV** to record the review.
{% endstep %}
{% endstepper %}
### How to find out who can see a report (or another item)
{% stepper %}
{% step %}
### Filter the object
In the **Object** filter, type at least 3 characters of the report name and select it. If there are items with the same name in different workspaces, also use the **Workspace** filter.
{% endstep %}
{% step %}
### Read each row
Each row is an access path: the **Principal** column shows who, **Access Right** shows the permission, and **Source** shows where it comes from (for example, *Via group: Finance* or *Via workspace permission*).
{% endstep %}
{% step %}
### Consider Power Embedded
If the Power Embedded integration is configured, the permissions granted in Power Embedded appear with the **Power Embedded** source.
{% endstep %}
{% endstepper %}
### How to find administrators and access granted individually
Use it to apply the principle of least privilege.
1. In the **Object Type** filter, check **Workspace**.
2. In the **Source** filter, check **Direct** to see only the permissions granted directly to people (and not through a group).
3. Go through the **Access Right** column looking for *Admin* and *Member*, or export to CSV and filter in Excel.
For the aggregated view (concentration of administrators, external accounts with write access), use the [Permissions Dashboard](/en/power-monitor/dashboards/dashboard-de-permissoes.md).
## Frequently asked questions
I added a person to a group, but they do not appear.
Open **View/manage collection →** and click **Refresh groups** on the [Group Members](/en/power-monitor/mapeamento/membros-de-grupos.md) screen. Group expansion uses a cache that is updated once a day by the scheduled scan and on demand by that action.
When I click "Refresh groups" (on Group Members), an error about application permission appears.
The organization's registered application does not have permission to read group members in Microsoft Entra ID. A tenant administrator must grant `GroupMember.Read.All` (or `Directory.Read.All`) as an **application permission**, with admin consent.
I filtered by workspace and the gateways disappeared.
Gateways, connections, and Power Embedded permissions do not belong to a workspace, so they leave the list when there is a workspace filter.
Why does the same person appear several times on the same report?
They may have access through different paths (direct, via group, via workspace). Each path is a row, identified in the **Source** column.
## Related pages
* [Permissions Dashboard](/en/power-monitor/dashboards/dashboard-de-permissoes.md)
* [Governance › Workspaces](/en/power-monitor/governanca/workspaces.md): users and permissions tab of each workspace
* [Governance › Infrastructure › Gateways](/en/power-monitor/governanca/infraestrutura/gateways.md) and [Connections](/en/power-monitor/governanca/infraestrutura/conexoes.md)
* [Settings › Audit](/en/power-monitor/configuracoes/auditoria.md): Power Embedded integration
* [Settings › Additional Permissions](/en/power-monitor/configuracoes/permissoes-adicionais.md): Microsoft Graph permissions
---
# 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/power-monitor/auditoria/auditoria-de-permissoes.md?ask=&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.
