TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

Project and User Grouping

12 posts · Jun 2014 – Aug 2025

What this trail covers

GitLab is evolving its organizational hierarchy features to better model team structures and enable advanced permissions management. This includes enhancing the capabilities of groups, subgroups, and projects to support strategic planning, value stream management, and cascading configurations. The inheritance model allows settings and permissions defined at higher levels to apply to lower levels, providing visibility and control across the organization. Best practices are provided for setting up organizational structures to align with Agile methodologies and optimize administrative overhead, security, and compliance. This iteration focuses on providing guidance for setting up group/subgroup/project structures for effective permissions management and strategic planning, including options for granting access at subgroup or any level, and best practices for milestones, labels, data management, and template creation.

All GitLab trails
  1. Fine-grained permissions for job tokens is now GAThis post announces the General Availability of fine-grained permissions for CI/CD job tokens. It details the initial set of resources for which granular permissions can be applied (repositories, deployments, environments, jobs, packages, pipelines, releases, secure files, Terraform state) and explains the security benefits, including reducing attack surface, eliminating dependency on long-lived tokens, and preparing for machine-based identity. It also provides guidance for getting started by auditing critical pipelines and enabling the opt-in capability.
  2. Custom admin roles are now GAIntroduced granular permissions for the Admin area in GitLab Self-Managed and GitLab Dedicated instances, allowing for the creation of custom admin roles. These roles enable the principle of least privilege for instance administration, with specific use cases for Platform, Support, and Leadership teams. Features include granular permissions, instance-level management, LDAP integration, and audit integration with Admin mode.
  3. Automating role-based access control (RBAC) at scaleThis post details the implementation of a Role-Based Access Control (RBAC) Accelerator program, demonstrating how to integrate GitLab with Keycloak and OpenID Connect (OIDC) for automated user provisioning and role mapping. It covers setting up a local Docker environment with GitLab and Keycloak, generating SSL certificates, configuring OIDC for authentication, and designing a scalable group hierarchy. The post emphasizes the practical application of least-privilege policies and how this foundation enables broader transformations like the Secure SDLC Accelerator.
  4. SAFe without silos in GitLabThis post details how GitLab's existing organizational structure (Groups, Subgroups, Projects) and work item hierarchy (Epics, Issues, Tasks) can be mapped to Scaled Agile Framework (SAFe) concepts and ceremonies. It explains how features like Roadmap, Epic boards, Issue boards, and iteration-scoped boards can be used to support PI Planning, Refinement, Sprint Planning, Daily Stand-ups, and Sprint Reviews. It also outlines implementation principles for adopting SAFe within GitLab, emphasizing the focus on ceremony objectives rather than exact tool replication, and defining conventions for work breakdown, iterations, milestones, and boards.
  5. Best practices to set up organizational hierarchies that scaleThis post details best practices for setting up organizational hierarchies in GitLab using groups, subgroups, and projects. It explains how to leverage the inheritance model for cascading settings, permissions, and configurations. Two primary options are presented: granting permissions at the organizational subgroup level (ideal for complex structures and efficient sharing) and granting permissions at any level (suitable for smaller organizations with less complex access needs). It also provides additional configuration considerations for milestones, iterations, data management, template creation, and labels, emphasizing how these elements can be managed at different levels of the hierarchy to promote consistency and visibility.
  7. Rate limitations announced for Projects, Groups, and Users APIsIntroduces rate limitations for Projects, Groups, and Users APIs to address increased server load and performance impacts. Details the rollout schedule, including brownouts and permanent implementation. Explains the feature flag strategy for GitLab.com vs. Self-managed/Dedicated instances, with default settings for new installations. Provides specific rate limits per endpoint for authenticated (user-based) and unauthenticated (IP-based) requests, and outlines the '429 Too Many Requests' response for exceeding limits.
  8. Small experiments, significant results and learningsThis post details experiments focused on improving the user invitation flow within GitLab. The first experiment involved adding an 'Invite members' link to the assignee dropdown for admin users, which led to a 2% increase in namespaces with two or more users. The second experiment tested showing the 'Invite members' link to non-admin users, presenting a modal that explained the feature's unavailability and provided contact information for admins. Encouraging results were observed, suggesting a demand for non-admin users to initiate invitations. A prototype for an 'Invite members' modal that allows in-workflow invitations is also presented.
  9. Don't hide primary actionsThis post details user research findings that highlight confusion among new users regarding the creation of subgroups and the distinction between groups and projects within GitLab. It identifies the primary problem as the discoverability of the 'New subgroup' action, which was hidden within a dropdown menu. Observations also indicated a lack of intuitive user experience for building organizational systems, with participants expecting graphical interfaces or command-line options. Solution proposals include splitting the 'New project' and 'New group' buttons to make the 'New group' action more discoverable and to separate disparate interface actions. The post concludes that this simple UI change significantly improved task completion time and user understanding.
  10. Integration management for git projectsIntroduced group-level integration management, allowing group owners and instance administrators to configure integrations for all projects within a group from a single place. This enhances security by allowing administrators to roll out integrations without sharing credentials with individual project owners. This feature is available for free on GitLab.com and self-managed instances running 13.6 and up. The post also outlines future considerations such as inheritance overviews, per-field inheritance, field masking, and inheritance locking. It also announces the deprecation of Service Templates in favor of this new group-level integration management.
  11. Managing multiple product categories in GitLabThis post details GitLab's approach to managing multiple product categories within a single repository by leveraging group-level issue boards and labels. It introduces scoped labels for `stage::name`, `group::name`, and `category::name` to organize issues by stage, team, and category. It also outlines labels for tracking workflow states (`workflow::state`) and issue types (`type::name`). The post explains how to configure group-level issue boards and shared milestones to align teams around a release cadence, providing a demo group for illustration. It also discusses alternative, less desirable approaches like the 'project approach' and 'single issue tracker project'.
  12. Feature Highlight: LDAP IntegrationIntroduced LDAP group synchronization for GitLab Enterprise Edition, allowing GitLab groups to be synced with LDAP groups. This automates user access management by granting members of a specified LDAP group a default access level within a GitLab group. Also documented potential pitfalls like locking oneself out and how nested ActiveDirectory groups are handled.
  13. GitLab Feature Highlight: GroupsThis post introduces the concept of GitLab Groups as a way to organize projects and manage user access across multiple projects simultaneously. It details how to create new groups, add projects to groups, transfer existing projects into groups, and manage group memberships. It also covers the ability to override project-level access for individual users within a group and discusses administrative controls for group creation and LDAP integration for group management.