### Release notes Previously, merge request approval policies supported only a single approval rule per policy, allowing for one set of approvers stacked with an “OR” condition. This reduced flexibility in setting distinct approval requirements, making it challenging for users to enforce layered security approvals from varied roles, individual approvers, or separate groups. With this update, users can create multiple distinct approval rules for merge request approvals, allowing for more flexible and robust approval policies. Each rule can specify separate approvers or roles and can be evaluated independently. This enables security teams to define complex approval workflows such as requiring one approver from Group A and one from Group B, or one from a specific role and another from a specified group, ensuring compliance and enhanced control in sensitive workflows. Possible example uses of this improvement include: **Distinct Role Approvals:** One approval from a Developer role and another from a Maintainer role.\ **Role and Group Approvals**: One approval from Developer or Maintainer and a separate approval specifically from the Security Group.\ **Distinct Group Approvals:** One approval from the Python Experts Group and another distinct approval from the Security Group. ### Problem to solve Scan result policies today support only a single action. Within the action, you can create an approval requirement to require approvals if any policy violation is detected in MRs based on the policy rules. Security approvals can be created in the MRs to require approval based on Role, from a set of Individual Approvers that are defined in the policy, or from users within a Group. You can stack the approvals with an OR clause only. However, this is limiting if you want to apply multiple sets of approval requirements for a given policy. Use Cases: 1. As a security team member, I want to create a merge request approval policy that requires approval from a set of individual approvers and then separately set approvals from users with a given role in the project, so that I can stack separate approval requirements. 2. As a security team member, I want to create a merge request approval policy that requires a set number of approvals from two separate groups - e.g. 1 approval from group 1, 1 approval from group 2, so that individuals from each group are required to approve the MR. Below is the current state with all possible options: {width="612" height="204"} Note that 1 approval here could be provided by: * A user with one or more roles * A user in the specified individual user list * A user from one or more groups specified You cannot: * Require 1 approver from Group A + 1 approver from Group B * Require 1 approver from a Developer role + 1 approval from the Security Group * Require 1 approval from a list of individuals 1-10 + 1 approval from individuals in a separate list 11-20 * Require 1 approval from Developer + 1 approval from Maintainer With this issue, we should allow for create of multiple distinct approval rules that support multiple combinations. ### Intended users ### User experience goal | Allow users to add a new distinct approval action | Use case: 1 approval from Role, 1 approval from Group | |---------------------------------------------------|-------------------------------------------------------| |  |  | | Use case: 1 approval from Any Role, at least 1 approval with Role Maintainer | Use case: 1 approval from Group A, 1 approval from Group B | |------------------------------------------------------------------------------|------------------------------------------------------------| |  |  | [Figjam concepts](https://www.figma.com/board/Z2aeQHvCF4SG71x5HCk0g5/Multiple-distinct-approval-rules?node-id=0-1&t=87YpwF3r0g60a3fz-0) ### Proposal 1. Allow users to create multiple distinct sets of approvers. 2. As an MVC we could start with a limit of 5 sets of approvers. 3. Each set of approvals would be isolated/distinct, meaning that in an MR each approval rule would be evaluated separately. One user may be able to satisfy multiple rules with their approval, but depending on the rule it may not. 4. Within an approval rule, it would still be feasible to add new approvers within the approval set - for instance, you could have a rule that allows 1 approval from any role, from groups A, B, and C, OR approval from a set of individuals. This would be a single "set" of approvals and 1 approval from each of the options could satisfy the rule. 5. Each approval action generates a distinct security approval in the MR. ### Further details ### Permissions and Security ### Documentation ### Availability & Testing ### Available Tier ### Feature Usage Metrics ### What does success look like, and how can we measure that? ### What is the type of buyer? ### Is this a cross-stage feature? ### What is the competitive advantage or differentiation for this feature? ### Links / references <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> _This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._ <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->