# Performing multi-level reviews Access reviews in BalkanID can be configured for a single reviewer or for multiple reviewers in a sequential order. This section explains how **multi-level reviews** work, ensuring user access reviews are thorough and accountable. *** ### Understanding Multi-Level Reviews Multi-level reviews are designed to add layers of oversight to the access review process. When you set up a multi-level review, you define a specific **reviewer order**, creating a chain of approval.Each reviewer in the sequence must take action before the review progresses to the next level. Only one reviewer at each level needs to approve for the review to proceed to the subsequent stage in the hierarchy. A key aspect of multi-level reviews is that a user can **edit their review decision at any time** until the overall campaign is marked as **completed** or **aborted prematurely**. This flexibility allows for corrections or changes based on new information. *** ### Example Scenario: Reviewer Order and Count Let's consider a scenario where the reviewer order is set as: 1. **First Line Manager** 2. **Risk Manager** 3. **Application Owner** Here's how BalkanID handles review assignments based on the **"Reviewer Count"** (the number of reviewers required at each level): * **Single Reviewer (1 Count):** Only one reviewer is required to act upon the review, which will be the first person in the reviewer order. If the first person in the order (e.g., the First Line Manager) is unavailable or if the identity's mapped employee has no first-line manager, the task will automatically escalate and be assigned to the next individual in the defined order (e.g., the Risk Manager). * **Two Reviewers (2 Count):** Two reviewers are required to act upon the review, which will be in the order of precedence (here, First Line Manager and Risk Manager). If the First Line Manager is unavailable, the review tasks will automatically be distributed to the next two available individuals in the order (e.g., the Risk Manager and the Application Owner). * **Three Reviewers (3 Count):** Three reviewers are required to act upon the review, which will be in the order of precedence (here, First Line Manager, Risk Manager and Application Owner). If the First Line Manager is missing and only two other reviewers are available in the sequence, the system will automatically adjust the number of required reviewers to two, assigning the tasks to those available individuals based on the set order. *** ### Handling Unmapped Identities or Absent Managers The system is designed to automatically adjust to the availability of assigned reviewers: * **Automatic Reassignment:** If the identity under review is unmapped or does not have an associated manager(in case the reviewer is the first line manager), the review will automatically be assigned to the next person in the predefined precedence order. *** ### Reviewer Progression and Decision Hierarchy The multi-level review process follows a strict progression, and each reviewer's decision impacts who can take action next. Let's look at an example with the sequence: **Reviewer A** → **Reviewer B** → **Reviewer C**. * **Reviewer A Approves:** * The review moves to Reviewer B. * **Reviewer A** can no longer change their decision (Deny) once the review progresses. * **Reviewer B** can **Approve** or **Deny**. * **Reviewer C** cannot take any action yet. * **Reviewer A Denies:** No further action can be taken by subsequent reviewers. The access is considered to be denied at this stage. * **Reviewer B Approves:** * The review moves to Reviewer C. * **Reviewer B** can no longer change their decision (Deny) once the review progresses. * **Reviewer C** can **Approve** or **Deny**. * **Reviewer A** can no longer take any action on this review. * **Reviewer B Denies:** No further action can be taken by subsequent reviewers once Reviewer B denies, even if Reviewer A approved. The access is considered to be denied at this stage. * **Reviewer C Approves:** * The review is now marked as **Approved** overall. * **Reviewer C** is the only one who can still **Deny** the review at this point (until the campaign is marked as complete by a Risk Manager or an Administrator). * **Reviewer A** and **Reviewer B** can no longer take any action on this review. This structured approach ensures that reviews progress through the designated hierarchy, with clear accountability and the ability to correct decisions until the campaign is finalized. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.balkan.id/user-access-reviews/access-review-management/tracking-campaigns-and-performing-access-reviews/performing-multi-level-reviews.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.