How do GitLab's group-level and project-level roles interact when a user has different roles assigned at each level?

GitLab resolves this by taking the highest of the two roles — a project-level role can grant a user more access than their group-level role alone would provide, but it can't be used to grant them less than the group role already provides; the group role acts as a floor, not a ceiling, for any project within that group.

Group membership in GitLab is inherited downward: adding a user as a Developer at the group level automatically gives them Developer access to every project within that group (and its subgroups), without needing to add them individually to each project. This inheritance is the baseline — the floor — for that user's access to any project in the group.

A project-level role, assigned directly and explicitly to a specific project (independent of group membership), can only ever increase that floor for that specific project, never decrease it. If a user is a Developer at the group level and is additionally given Maintainer access directly on one specific project within that group, they effectively have Maintainer access to that project (the higher of the two) while remaining a Developer everywhere else in the group. What GitLab does not support is the reverse — there's no mechanism to explicitly reduce a user's access on one project below what their group membership already grants them; if someone is a Maintainer at the group level, they're a Maintainer on every project in that group, full stop, regardless of any project-level setting, since the inherited group role can't be locally overridden downward.

This has a practical consequence worth being deliberate about: broad group-level role assignments (making someone a Maintainer at the group level "for convenience") propagate that access to every current and future project created within the group — a much bigger grant than it might appear at assignment time, since it's not scoped to what exists today. The more precise, least-privilege approach for access that's genuinely only needed on specific projects is assigning at the project level directly rather than reaching for a broad group-level grant, reserving group-level roles for access that's genuinely meant to apply uniformly across the whole group's current and future projects.

• GitLab resolves group-level and project-level role differences by taking the highest of the two — group role is a floor, not a ceiling.
• A project-level role can grant more access than the group role alone provides, for that one specific project.
• There's no mechanism to reduce a user's access on one project below what their group-level membership already grants them.
• Broad group-level role assignments propagate to every current and future project in the group — worth being deliberate about, versus scoping access at the project level when it's genuinely project-specific.

• GitLab Docs: Roles and permissions
• GitLab Docs: Group membership