<!--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=505744) </details> <!--IssueSummary end--> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Problem to solve When using a (sub)group for approval rules, it includes all direct members even group access tokens (bot users). This causes confusion for most users looking to see who can approve a MR. Example: https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/10097 ### Proposal Hide group access token accounts from approval rules by default. Potentially provide an option for group owners to display them by default (as they may have some kind of automation set up). ### Intended users Any ### Feature Usage Metrics <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Explore (../../doc/development/internal_analytics/internal_event_instrumentation/quick_start.md) for a guide. --> ### Does this feature require an audit event? No