<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=394733) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal **As a** member of an organisation with thousands of users, multiple compliances and strict processes created around software integration, **I want to** be able to set required approvals from different users or teams towards the same changeset, **so I can** make sure that changes to critical components are approved not only by _any_ eligible approver, but by _each one_ of (or at minimum one of each group) that I define. ### Example A real use case example can be seen at [378181](https://support.gitlab.com/hc/en-us/requests/378181). My organisation has several use cases where some **key people** or **teams** are required to approve a given changeset. With the current **approval rules** and **CODEOWNERS**, it's only possible to specify what are the eligible approvers and how many approvals are required, but there's no way to require at leat one approval from each eligible approver (person) or team. With the current rules, if I require 3 approvals from 3 teams, this means any 3 approvals are valid, even if they all come from the same team. ---- <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->