Make Minimal Access users non-billable on Self-Managed Premium subscriptions

Problem

Restricted Access (RA) requires Minimal Access (MA) users to be non-billable on Premium subscriptions to function properly. RA uses MA as a fallback role when identity provider syncs (SCIM/LDAP/SAML) attempt to add users beyond the seat limit. Without this change, the RA feature cannot work as designed.

Currently, MA users are:

  • Non-billable on GitLab.com Premium and Ultimate
  • Non-billable on Self-Managed Ultimate
  • Billable on Self-Managed Premium ← this needs to change

Proposal

Make Minimal Access users non-billable on Self-Managed Premium subscriptions to enable Restricted Access functionality.

Context

What is Minimal Access?

Minimal Access is a highly limited role that can only be assigned at the top-level group (not in subgroups or projects). Users with Minimal Access cannot access subgroups or projects within that top-level group, making it primarily useful for organizational visibility rather than active development work.

Quote from @jrandazzo, highlighting mine:

Minimal access makes sense to be non-billable for all distributions. It is a way to provision users without assigning access, especially on GitLab.com. As organizations come into the picture, I could see the concept of "Minimal Access" going away as users would be provisioned at Organizations without access, then assigned membership accordingly. We are far out on this though.

Revenue Impact Analysis

GitLab.com data (from issue):

  • 2,066 users with MA role on Premium parent namespaces (as of December 15, 2025 - spreadsheet)
  • MA already non-billable on .com Premium → $0 revenue impact on .com

Self-Managed Premium data:

  • Unknown MA user counts (no Service Ping data available)
    • MA currently billable on SM Premium, so usage patterns may differ
    • We manually collected data from 28 Self-Managed Premium customers (96,226 total billable seats):
      • 27 customers: 0 MA users
      • 1 customer: 2 MA users
      • MA usage: 0.002% of licensed seats in the customer sample
  • We're adding instrumentation to gather this data going forward (issue), but won't have sufficient data soon enough (requires 18.8 upgrade + 75% Service Ping opt-in rate)

Business Justification

Revenue protection from enabling RA:

  • See comment for data on failed QSR payments
  • Improved auto-renewal success rates

Operational cost savings:

  • 50% reduction in billing-related support tickets
  • Reduced collections team effort on failed QSR recovery
  • Decreased finance team time on overage reconciliation

See comment for additional info.

Technical Necessity

Alternative solutions (failing IdP provisioning when seat limit reached) would require:

  • Significant re-work of existing RA implementation
  • Poor, inconsistent UX across different identity providers
  • Reverting completed work from milestone 18.7

See Slack discussion for technical details.

Related Issues

  • Revenue impact analysis.
  • #584109 (closed) - Add MA user count instrumentation to Service Ping
  • !210596 (merged) - Original implementation (reverted)
  • Make `minimal access users` or `users not assig... (#330663 - closed) - original issue, closed in favour of this one

Implementation Notes

This change aligns SM Premium billing behavior with GitLab.com Premium and SM Ultimate, where MA users are already non-billable.

Approvals

  • @courtmeddaugh
  • @abhaskar-gl (based on comment)
  • @james.shen (based on comment
  • @spatching (see comment)
  • @manav-gl (based on comment)
  • @jlatendresse (based on comment)
  • @dtuan (in place of @SeanHall, OOO)
Edited Feb 12, 2026 by Magdalena Frankiewicz
Assignee Loading
Time tracking Loading