> 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/historico-de-permissoes.md).

# Permission history

See who gained, lost or changed access to workspaces and artifacts over time and rebuild who had access on a past date.

The **Permission history** screen answers two questions that the [Permissions Audit](/en/power-monitor/auditoria/auditoria-de-permissoes.md) (which shows the **current** state) does not: **what changed?** (who gained, lost or had their role changed) and **who had access on a given date?**. Each change is detected by comparing one permission collection with the previous one.

**How to access:** menu *Audit › Permission history*.

**Who can use it:** all profiles, within each user's **workspace scope**. API access follows the same page control as the [Permissions Dashboard](/en/power-monitor/dashboards/dashboard-de-permissoes.md). An administrator can block the page for specific users in [Users](/en/power-monitor/usuarios.md).

<figure><picture><source srcset="/files/A8DL45c5D8KE7HlX0kti" media="(prefers-color-scheme: dark)"><img src="https://3938213054-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH2bFRBmIfyK3kwVKbldl%2Fuploads%2Fgit-blob-573337e91f113dfe9c6debc404deaff79baea802%2Fpm-auditoria-historico-permissoes-en.png?alt=media" alt="Permission history screen with the Changes and Who had access on tabs, the change type, principal, workspace and period filters and the list of access changes"></picture><figcaption><p>Audit › Permission history, Changes tab</p></figcaption></figure>

{% hint style="info" %}
**The history starts when the feature went live.** The first observation of a workspace (or artifact) creates a **baseline**, with no "Granted" events: only changes from then on appear. The date shown is that of the **collection that noticed the change**, not when it happened in the tenant.
{% endhint %}

## What it is for

* **Investigate** when and for whom an access was granted or revoked.
* **Prove** (in audits) who had access to a workspace or artifact on a past date.
* **Track** role promotions (for example, from Viewer to Admin) and the arrival of apps, groups and guests.

## Changes tab

The **Access changes** list (*Newest first. Click a row to see the principal's timeline*) has these filters:

| Filter          | Options                                                                                                                     |
| --------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Change type** | **All types**, **Granted**, **Revoked** or **Role changed**                                                                 |
| **Principal**   | Name or key (press Enter to apply)                                                                                          |
| **Workspace**   | **All workspaces** or one workspace                                                                                         |
| **Period**      | 7, 14, 30 (default), 60, 90 or 180 days, or a custom range (maximum 180 days); the button also shows the dates of the range |

| Column          | Content                                                                    |
| --------------- | -------------------------------------------------------------------------- |
| **Detected at** | Date and time of the collection that noticed the change                    |
| **Principal**   | Person, group, app or another principal                                    |
| **Change**      | **Granted**, **Revoked** or **Role changed**                               |
| **Role**        | Role after the change (**Admin**, **Member**, **Contributor**, **Viewer**) |
| **Workspace**   | Affected workspace                                                         |
| **Target**      | **Workspace** or the **artifact** (with its type) whose access changed     |

Results come from the server in batches of 100, with the **Load more** button (which reports how many changes are already loaded out of the total). The table shows 10 rows per page, with an items-per-page selector, and can be sorted by clicking the column titles (default: **Detected at**, newest first). On **Role changed**, the **Role** column shows the previous role, an arrow and the new role. The **Refresh** button in the header (available on the **Changes** tab) runs the query again. The **More actions** menu of each row (also with right-click) offers **View principal timeline**, which opens a drawer with that principal's changes (up to the 500 most recent), and **Copy key**, useful for the next tab.

The **Export** button (CSV or JSON) takes **only the loaded rows**, not the whole server result; use **Load more** before exporting to include more rows.

## "Who had access on" tab

<figure><picture><source srcset="/files/ok3U27ayCAzTeRH88Dxm" media="(prefers-color-scheme: dark)"><img src="https://3938213054-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FH2bFRBmIfyK3kwVKbldl%2Fuploads%2Fgit-blob-5d189e5957a8e755f4cde608e9a0f86b88cab7c8%2Fpm-auditoria-historico-permissoes-quem-tinha-acesso-en.png?alt=media" alt="Who had access on tab with the Date, Principal and Workspace fields, the Look up button and the result with the summary of access on the date"></picture><figcaption><p>Who had access on tab</p></figcaption></figure>

It rebuilds access **at the end of the chosen day**, from the current state and the changes recorded after it.

| Field                     | Notes                                    |
| ------------------------- | ---------------------------------------- |
| **Date**                  | Starts at today; cannot be in the future |
| **Principal (exact key)** | Use the key as shown by **Copy key**     |
| **Workspace**             | One workspace                            |

Provide the date and **at least one** of principal and workspace: the lookup is not run over the whole organization. Click **Look up**.

The result shows *Access at the end of \[date]: N grants* and the list, which can be exported. The table has **Principal**, **Role**, **Workspace** and **Target**, is paginated and sortable, and each row has the **View principal timeline** button. Possible notices:

* **No coverage for \[date]:** *this does not mean nobody had access*; the history simply cannot rebuild that date. The reasons are: the date is **outside the retention window** (events are kept for **400 days**), it is **before the organization's history started**, or **there is no history** recorded yet.
* **N workspaces or artifacts were only observed after that date** and are left out of the list.
* **The result was cut by a limit:** the list may be incomplete; narrow it by principal or workspace.

## Rules and behavior

* **How it is detected:** at each permission collection, Power Monitor compares each principal's access on each workspace and artifact with what was stored. New principal = **Granted**; principal that disappeared = **Revoked**; different set of roles = **Role changed**. Reordering roles is not a change.
* **Privacy:** the principal's name and key are identity and respect the **Hide data** button (also in exports).
* **Retention:** events are kept for 400 days.
* **Scope:** users with restricted visibility see only the workspaces in their scope.

## Step by step

### How to find out who had access to a workspace on a date

{% stepper %}
{% step %}

### Open the tab

In *Audit › Permission history*, open **Who had access on**.
{% endstep %}

{% step %}

### Choose the date and the workspace

Provide the **Date** and the **Workspace** (or the **Principal**, using the key copied on the **Changes** tab).
{% endstep %}

{% step %}

### Look up

Click **Look up** and read the summary. If **No coverage** appears, the date is outside the available history.
{% endstep %}
{% endstepper %}

### How to see everything that changed for a person

1. On the **Changes** tab, filter by the **Principal** and press Enter.
2. Click a row to open the **Principal timeline**.

## Frequently asked questions

<details>

<summary>Why do I not see old changes?</summary>

The history starts when the feature went live and keeps events for 400 days. The first observation of each workspace is just the baseline.

</details>

<details>

<summary>The date of the change does not match what the administrator remembers.</summary>

The date shown is that of the collection that noticed the change, not the moment it happened. The change happened between the previous collection and this one.

</details>

<details>

<summary>The lookup says "No coverage". Does that mean nobody had access?</summary>

No. It only means the history does not allow rebuilding that date.

</details>

## Related pages

* [Audit](/en/power-monitor/auditoria.md)
* [Permissions Audit](/en/power-monitor/auditoria/auditoria-de-permissoes.md)
* [Permissions Dashboard](/en/power-monitor/dashboards/dashboard-de-permissoes.md)
* [Access reviews](/en/power-monitor/governanca/conformidade/revisoes-de-acesso.md)
* [Direct Sharing](/en/power-monitor/auditoria/compartilhamento-direto.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/power-monitor/auditoria/historico-de-permissoes.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.