<!-- 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 --> ## Background _This epic was created by splitting https://gitlab.com/groups/gitlab-org/-/epics/4367 into two components. The other epic is intended to capture the use case for group-level settings for merge request approval **rules**._ Compliance-minded organizations manage their GitLab namespaces against company policy to ensure the use of GitLab does not create gaps in their audit posture. One of the most common requirements for these organizations is separation of duties; one of the primary controls that exists within GitLab to support this requirement are merge request approvals. ## Problems to solve Tracking and managing [Merge Request approval settings](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/settings.html) across a large number of projects can be incredibly time consuming and lead to surprises during an audit if a configuration was not caught. Currently, group owners must go into every project and manage their configuration individually. This can be time consuming and is error prone. ## Intended users [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) ## Job statement > When restrictions are necessary, I want to configure an environment, so that I can ensure we are compliant. ## Proposal To avoid breaking changes the goal is to accomplish two things: 1. Parity of control over Approval settings between the Group Level and Admin area 1. Make the UI copy and order consistent between the various layers Vision screenshots, [Figma →](https://www.figma.com/file/C54tpWqeMRcZPmNYFRnkAo/%F0%9F%94%92-and-4552-and-4367-Improve-MR-approvals-experience-instance-group?node-id=4294%3A23708) > **Illustrative Scenario:** An administrator has already prevented approval of Merge Requests by committers, and a group owner wants to extend the restriction by preventing approval of Merge Requests by author. Project maintainers cannot change these settings, but it's clear where the restriction was established. | Instance | Group | Project | | -------- | ----- | ------- | |  |  |  | |Enforced by Instance|Enforced by Group| |--------------------|-----------------| |  |  | Is this a cross-stage feature? --- :handshake: ~"group::compliance" ~"group::source code" ~"group::code review" Open questions to answer --- * [ ] _Fill in & update this list over time_ --- Have feedback on this feature? Please share your thoughts [here](https://gitlab.com/gitlab-org/gitlab/-/issues/285342).