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 | Not Applicable |
| Content Last Reviewed | 2023-05-15 |
Thanks for visiting this category direction page on Organizations at GitLab. The Organization category is part of the Tenant Scale group within the Enablement 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 discussion with Sid on this topic outlining the problem and the concept of an "instance group". We have since moved away from the term "instance group" and are instead using the term "organization".
The video below gives a walkthrough of our MVC plan for Organization.
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 level rather than the instance level at a minimum.
We should extract features from the admin panel into a new object called Organization that cascades behavior to all the projects and groups that are owned by the same user or organization.
The Organization group focuses on creating a better experience for organizations to manage their GitLab experience. 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. This also introduces a new concept for feature parity between projects, subgroups and groups. The result of this effort will be a more intuitive user experience for all our users towards more aligned behaviors throughout our product.
Namespace is the logical object container in the code. Organization is the name for the entity that hosts top-level groups.