> For the complete documentation index, see [llms.txt](https://docs.balkan.id/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.balkan.id/user-access-reviews/access-review-management/tracking-campaigns-and-performing-access-reviews/performing-multi-level-reviews.md). # Multi-Level & Multi-Approval Reviews Access reviews in BalkanID can be configured for a single reviewer, for multiple reviewers acting in sequence, or for multiple reviewers acting together at the same point in that sequence. This section explains how **multi-level reviews** and **multi-approval reviews** work, ensuring user access reviews are thorough and accountable. {% hint style="info" %} Per-level reviewer counts (multi-approval) and multi-level reviewers are enabled per tenant. If you don't see them in reviewer precedence settings, reach out to your BalkanID contact to have it turned on. {% endhint %} *** ### Understanding multi-level and multi-approval 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 — for example **First-line Manager**, then **Risk Manager**, then **Application Owner**. Each level in that order acts in turn, and the review only moves to the next level once the current one is resolved. Resolving a level can mean one reviewer at that level taking action, or it can require **more than one distinct reviewer** to approve before the level is considered resolved — for instance, requiring two of the **Business Owner(s)** on an application to independently sign off rather than just one. This required approval count defaults to one per level, and **First-line Manager** is always limited to one, since an identity can only have one manager. 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, Levels, and Approval Counts Let's consider a scenario where the reviewer order is set as: 1. **First Line Manager** 2. **Risk Manager** 3. **Application Owner** The **Number of Reviewer Levels** determines how far down this order a review has to travel before it's fully approved: * **One level:** Only the first person in the order needs to act — the First Line Manager. If the identity's mapped employee has no first-line manager, the task automatically escalates to the next individual in the order, the Risk Manager. * **Two levels:** Reviewers act in order of precedence — First Line Manager, then Risk Manager. If the First Line Manager is unavailable, the tasks are automatically distributed to the next two available individuals in the order, e.g. Risk Manager and Application Owner. * **Three levels:** All three act in order — 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 automatically adjusts the requirement to two levels, assigning the tasks to those available individuals in order. Independently of how many levels are required, any given level can also require more than one approval. If, say, the Application Owner level is configured to require two approvals, the review won't advance past that level until two distinct Application Owners have approved it — and if only one Application Owner exists for that application, the requirement is automatically capped to the one available, so the review is never left waiting on an approval that can't be given. *** ### Handling Unmapped Identities or Absent Managers The system is designed to automatically adjust to the availability of assigned reviewers. If the identity under review is unmapped, or doesn't have an associated manager, the review is automatically assigned to the next person in the predefined precedence order. The same principle applies when a level requires multiple approvals: if there aren't enough distinct reviewers available at that level to satisfy the configured count, the requirement is automatically reduced to however many reviewers actually exist there. {% hint style="warning" %} A level will never get stuck waiting for more approvals than there are reviewers available to give them. {% endhint %} *** ### 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. Where a level requires multiple approvals, this same logic applies within the level before it's considered resolved: any one of the required reviewers denying the item is enough to deny it at that level, while the level only progresses once every one of the distinct approvals it requires has been given — at which point those reviewers, like Reviewer A and B above, lose the ability to change their decision. This structured approach ensures that reviews progress through the designated hierarchy — across levels and within them — with clear accountability, while still allowing decisions to be corrected right up until the point they're finalized. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` 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=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.