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)