The following 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.
| Stage | Data Stores |
| Maturity | Planned |
| Content Last Reviewed | 2023-11-13 |
Thanks for visiting this category direction page on Organizations at GitLab. The Organization category is part of the Tenant Scale group within the Core Platform section and is maintained by Christina Lohr.
This vision and direction is constantly evolving and everyone can contribute:
The Organization category focuses on creating a better experience for organizations to manage their GitLab implementation. This includes making administrative capabilities that previously only existed for self-managed users available to our SaaS users as well, such as management of users and groups and supporting cascading settings. The result of this effort will be a more intuitive user experience for all our users towards more aligned behaviors throughout our product.
Iterating on Organizations will allow us to solve a number of problems with the current SaaS experience:
The video below contains a high-level overview of what the Organization is trying to accomplish, some initial design considerations, and how Organizations build the foundation for Cells.
Today, GitLab's features exist at 3 levels:
| Level | Description | Example |
|---|---|---|
| Instance | Features for the entire instance. These are generally admin features (restricted to the admin panel or via a config like gitlab.rb), but not always (Operations Dashboard). |
LDAP, admin-level push rules |
| Group | Features configured and used at the group-level. These generally inherit behavior or objects down into subgroups (like epics, settings, or memberships). | Epics |
| Project | Features used at the project level. | Requirements Management |
This leads to a few problems:
While it would be ideal to have one way to build a new feature, most GitLab functionality should exist at the group or organization level rather than the instance level at a minimum.
We should extract features from the Admin Area into a new object called Organization that acts as an umbrella to all the projects and groups it contains.
The Organization focuses on creating a better experience for organizations and enterprises to manage their GitLab experience. By introducing Organizations and Cells we can improve the reliability, performance and availability of our SaaS Platforms.
Over the next few months, we are focussing on delivering an Organization MVC. The MVC serves as a foundation for Cells and for other teams to add functionality that is needed at the Organization level. The Organization MVC will contain the following functionality:
Once established, we want to focus on improving workflows and functionality for users of the organiztion by addressing the following gaps:
internal visibility is only available on self-managed GitLab, and the only way for customers of GitLab.com to shield their content is to set the visibility of all of their groups and projects to private. This setting is often too restrictive for users to easily find their way around an Organization. By making internal visibility available, administrators can enable their users to safely explore projects without having to supervise their membership.Within the next year, we are planning to release the Organization MVC. We have defined an iteration plan that outlines how we intend to arrive at the Organization MVC.
Our immediate focus is to release an Organization prototype containing: