> For the complete documentation index, see [llms.txt](https://boza.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://boza.gitbook.io/docs/user-management/access-reviews.md).
# Access Reviews
Run recurring access-certification campaigns, collect a confirmation from each application owner, and retain an audit-ready record of the result.
The campaign dashboard is the administrator view for configuring, launching, and monitoring access reviews.
{% hint style="info" %}
Access Reviews has two distinct experiences: **workspace administrators** manage campaigns, while **Access Reviewers** complete only the reviews assigned to them in **My reviews**.
{% endhint %}
***
## Who Can Do What?
| Role | Access |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Workspace administrator** | Configure the recurring schedule, send test reviews, launch or cancel campaigns, monitor progress, and export results |
| **Access Reviewer** | Review and confirm access for the approved applications assigned to them |
| **Super Admin fallback** | Receives the review for an app only when no Access Reviewer is assigned and the fallback option is enabled |
Being an application reviewer does not grant access to campaign administration. A reviewer sees only their own assigned records.
***
## How a Campaign Works
1. An administrator marks the applications in scope as **Approved** and assigns Access Reviewers.
2. The administrator can send a small **test review** before starting a live campaign.
3. Boza launches the campaign on its configured date, or an administrator launches it immediately.
4. Each reviewer receives one invitation listing only their assigned applications.
5. Reviewers confirm each application individually and may leave a comment.
6. Administrators follow progress from the campaign dashboard and export the completed record to CSV.
Boza takes a snapshot of the application and reviewer details when the campaign launches. This preserves the audit trail even if an app or owner is changed later.
***
## Campaign Scope and Reviewer Selection
Only **Approved** applications are included in a live campaign.
For each approved application, Boza applies these rules:
1. Assign the review to every Access Reviewer configured for that application.
2. If there is no Access Reviewer and **Notify the Super Admin when no Access Reviewer is assigned** is enabled, assign it to the app's Super Admin.
3. If neither is available, record the application as **Not covered** so the ownership gap remains visible.
{% hint style="warning" %}
Assign reviewers before launch. Updating an application's owners after a campaign starts does not rewrite that campaign's records.
{% endhint %}
***
## Status Glossary
### Campaign statuses
| Status | Meaning |
| ------------- | --------------------------------------------------------------- |
| **Scheduled** | A future occurrence calculated from the recurring configuration |
| **Running** | The campaign is open and reviewers can submit confirmations |
| **Closed** | The deadline has passed and the campaign is no longer editable |
| **Cancelled** | An administrator stopped the campaign before it closed |
### Review statuses
| Status | Meaning |
| --------------- | ----------------------------------------------------------------- |
| **Pending** | The reviewer has not yet submitted the review |
| **Completed** | The reviewer confirmed the application |
| **Incomplete** | The campaign closed before the reviewer submitted |
| **Not covered** | No Access Reviewer or eligible Super Admin fallback was available |
When a running campaign reaches its deadline, Boza closes it automatically and changes any remaining **Pending** records to **Incomplete**.
***
## In This Section
| Guide | Use it when |
| --------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
| [Configure and Manage Campaigns](/docs/user-management/access-reviews/configure-campaigns.md) | You are an administrator preparing, launching, monitoring, or exporting a campaign |
| [Complete an Access Review](/docs/user-management/access-reviews/complete-a-review.md) | You received a review invitation or have pending items in **My reviews** |
***
## Best Practices
* Assign at least one Access Reviewer to every approved application.
* Use the Super Admin fallback as a safety net, not as a substitute for clear reviewer ownership.
* Send a test review after changing the configuration or reviewer assignments.
* Choose a deadline that gives reviewers enough time and leaves room for follow-up.
* Investigate **Not covered** and **Incomplete** records before treating a campaign as complete.
* Export the final CSV and retain it with your audit evidence.
For application ownership and approval status, see the [App Detail Page](/docs/inventory/applications/app-detail.md). For other downloadable data, see [Reports & Exports](/docs/resources/reports-and-exports.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://boza.gitbook.io/docs/user-management/access-reviews.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.
