Administrator account on self-managed instance should not be counted as a seat

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

[This issue will remain open while it serves as a resource with valuable feedback and discussion around the billable status of an administrator in our seat model. These contributions can help inform the decisions for future iterations in this space and we will continue to monitor the conversation here while related work may be tracked elsewhere.]

[Updating the description to reflect the decision in this conversation (internal note)]

Problem

Currently, Admin role on Self-Managed GitLab instances is counted occupies a seat (and is considered billable).

Note that users with Admin role that do not have Groups/Projects memberships are non-billable in Ultimate (see comment here (internal note))

Proposal

Create a non-billable Admin. In other words, create and Admin role and then have a way to assign it as non-billable. The idea is to limit what the Admin role can do (e.g., can't use features within Groups/Projects, etc.).

This will most likely be done in the scope subscription seat based model.

Previous description

Problem

The Administrator account on a self-managed GitLab instance is counted as a seat within the license. This is costly and goes against many security and administration best practices.

Proposal

We could do one of two things:

  1. Introduce an Administrator role that does not count towards a seat. This role also can impersonate other users, but when an attempt is made to add the user to a group or a seat we present with a banner message stating Root users cannot be added to projects or groups. For more information, please check out our user roles and permissions documentation page.
  2. Users that are not added to a group or project are not counted towards seats.

Result

Clearer user management and alignment with other competitive products within the self-managed application toolset, such as JIRA.

Next steps (if any)

@jeremy_ what do you think of this? I'm not 100% sure on number 2. and how we currently handle that situation.

Support Priority Score: (-, -, -, -, -, -, -, -, -, -, -) => 13

Edited by 🤖 GitLab Bot 🤖