> ## Documentation Index
> Fetch the complete documentation index at: https://docs.opal.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Assign and complete reviews
> Learn how to assign and complete User Access reviews in Opal.
This guide assumes you have already [created a User Access Review](/docs/access-reviews).
## Assign reviewers
If you don't see an option to assign reviewers, ensure you're an **Opal
Auditor** or an owning team admin.
If you are an **Auditor **or **owning team admin**, you can assign reviewers.
In the **User Review** tab, you can manage and assign reviewers for user access points. Assign reviewers to a single user row by clicking **Assign Reviewers** for that row, or bulk assign by selecting multiple rows and clicking **Assign Reviewers** in the top right. If you've chosen an auto-assignment policy, you can still manually re-assign reviews.
In the **Group Review** tab, you can manage and assign reviewers for group access points. Assign reviewers to a single user row by clicking **Assign Reviewers** for that row, or bulk assign by selecting multiple rows and clicking **Assign Reviewers** in the top right.
After you assign a reviewer, Opal shows one of several reviewer statuses.
The following are possible status types:
* **Not Started: **No reviewer(s) have taken action
* **Completed**: All reviewer(s) have completed the review
* **Partially Completed: **If there is only one reviewer, then the reviewer has started but has not completed the review. If there are multiple reviewers, then not all reviewers have completed the review.
* **Needs Attention:**
* This status type indicates an error that needs to be addressed. Click on the **Needs Attention **status to see error details. In this example, the warning indicates **Self reviews are not allowed**, and an admin must add another owner for approval.
## Complete reviews
After an admin assigns a reviewer, a snapshot for the resource and/or group is created for review. If an admin changes a resource or group after a review begins, the review won't capture this change.
**My Reviews** shows reviews assigned to the logged-in user. After reviewers select a row to review, they are shown an overview of users and groups whose access to a resource must be reviewed.
To review access for a resource or group, ensure you select the **row**, not
the resource or group name.
The **Group by User** and **Group by Resource** buttons control how reviews are grouped, which can be useful to change based on your requirements. These options are available on Opal Cloud and self-hosted Opal versions 1.0.912 and later.
For each row, reviewers can:
* **Approve** the user or resource by clicking on the **Accept** checkmark button
* **Reject** the user or resource by clicking on the **Revoke** x button
* Select **Add note** to explain access decisions:
UAR reviewers can also modify a user's role by selecting **Swap Roles** in User \< > Resource and User \< > Group mappings. This creates a request that follows the access request flow configured for that resource. This request has to be approved by that resource's reviewers in order for the role modification to propagate.
If there is no request flow configured, the user's role will not be modified.
A notification will be sent to the reviewer that an attempt to modify that
user's role has failed.
**Bulk action** can be performed on multiple rows by selecting rows and choosing an option from the top bulk action bar.
After you review all users or resources, select **Submit access review** in the bottom right. You cannot modify approvals and revocations after you've submitted. Changes are only propagated to end systems when all the UAR's items have been reviewed and the review is marked as completed.
### Access Changes
To view and manage proposed changes, go to the **Access Changes** tab.
### Revocation rules
**For connected applications**, Opal automatically revokes access on the end system based on the reviewer's decision, so after submitting a revoke decision, you do not need to perform any more actions.
If your connection uses a **custom connector**, you must implement the [DELETE](/docs/api-spec#delete-%2Fgroups%2F%7Bgroup-id%7D%2Fusers%2F%7Buser-id%7D) `/groups/{group_id}/users/{user_id}` or [DELETE](/docs/api-spec#delete-%2Fresources%2F%7Bresource-id%7D%2Fusers%2F%7Buser-id%7D) `/resources/{resource_id}/users/{user_id}` endpoints to revoke users on your end system.
If the endpoint returns a 200 success code, Opal marks the access as revoked. If the endpoint is not implemented or returns an error code, access is marked **Needs end-system revocation** and you must manually update it.
If the connection uses **webhooks**, access will be marked as **Needs end-system revocation**, because webhooks only perform push events. Opal does not interpret webhook responses, so you'll need to manually mark access as revoked.