# Restricted Access feature completion epic ## Problem statement Customers currently face unexpected overage fees when they exceed their purchased seat limits, creating billing confusion and customer support burden. While Restricted Access feature, that blocks seat overages exists for [.com](https://docs.gitlab.com/user/group/manage/#turn-on-restricted-access) and [self-managed instances](https://docs.gitlab.com/administration/settings/sign_up_restrictions/#turn-on-restricted-access), it has [known issues](https://docs.gitlab.com/user/group/manage/#known-issues) that prevent feature enforcement for chosen customer group and feature adoption by all other willing customers. ## Solution overview Complete the Restricted Access (RA) feature to prevent customers from exceeding purchased seats. When enabled, RA ensures that **max seats used** equals **seats in subscription** and **seats owed** remains zero. **Current state:** Restricted Access is available but has [known issues](https://docs.gitlab.com/user/group/manage/#known-issues), particularly with user management protocols (SCIM/SAML/LDAP). **Target state:** Fully functional Restricted Access that customers can enable for themselves and that can be enabled to chosen cohorts of customers. ## Business value Detailed [Business case](https://gitlab.com/gitlab-org/gitlab/-/work_items/582950). - Eliminate billing confusion by aligning billable users with purchased seats - Reduce support overhead from customer billing questions - Progress toward reduction of processing needed for dealing with seat overages, see [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/12014#note_2562262469) - Reduction in revenue loss for GitLab, see [here](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/12014#note_2562262469) - Get data on customer preferences for overage prevention ## Requirements ### Core functionality - **Block external group sharing** when RA is enabled - **Disable user caps** (incompatible with RA) - **Allow non-billable user additions** when seats are exhausted - **Prevent billable role changes** when no seats remain ### User management protocol support - **Block billable user additions** via SCIM/SAML/LDAP when seats exhausted - **Notify administrators/Owners** to purchase additional seats - **Add users with Minimal Access role** (non-billable) when seats unavailable, RA is on and provision done by SCIM/SAML/LDAP - Minimal Access role needs to non-billable on SM Premium - [issue](https://gitlab.com/gitlab-org/gitlab/-/work_items/584275) - done - MA is non-billable on SM Premium from 18.9 - users with Minimal Access need to visible in the top-level group hierarchy -\> they already are, see [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/580311#note_2940318628). ### Works with other features - Users can [import members from another project](https://docs.gitlab.com/user/project/members/#import-members-from-another-project) - RA should account for this scenario as well, block going into overages and give clear messaging to users <details> <summary>Regarding user management protocols</summary> - Advise on SAML/SCIM/LDAP in [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/432733#note_1881366622) and [decision](https://gitlab.com/gitlab-org/gitlab/-/issues/432733#note_1941205500) - [Learned](https://gitlab.com/gitlab-org/gitlab/-/issues/458312#note_1913012989) from `@hsutor` that there is a consensus among other companies that the "we leverage user management protocols but ran out of available purchased seats" problem is solved downstream of the IdP/protocol. </details> ### User experience - **Clear messaging** explaining seat limits and purchase options - **Proactive warnings** when approaching seat limits - **Smooth purchase flow** for additional seats ## Open decisions 1. **Pending approval queue:** Should users be queued for approval when seats are unavailable? -\> No, we won't utilise approval queue. When seats are unavailable we won't allow adding more billable users. 2. **SAML user handling:** Block completely, queue for approval, or assign minimal access? -\> Decided to use Minimal Access role as a fallback; RA uses MA as a fallback role when identity provider syncs (SCIM/LDAP/SAML) attempt to add users beyond the seat limit. 3. **Zuora integration:** Remove Zuora flag in favour of GitLab feature flag? Probably not, as rolling this feature out should probably depend on how customers are now paying for overages. See the rollout strategy issue -\> We keep Zuora flag and use it for rollout. 4. **License downgrades:** How to handle renewals with fewer seats than current usage? 5. Added: New TBD related to users without membership on SM Premium being billable are listed [here](https://gitlab.com/gitlab-org/gitlab/-/issues/571300#note_2959475628), <details> <summary>Details to open decisions</summary> - Decision needed on blocking SAML users or putting them into pending approval state or add them in with Minimal Access. Approval Queue is described in scenarios in [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/508783) and it seems it would be a rather complex solution. Currently we're leaning towards adding users to top-level group/instance with Minimal Access role (non-billable) and messaging action taker/group Owner/Admin on this and prompt them to buy more seats. - [Thread](https://gitlab.com/gitlab-org/gitlab/-/issues/432733#note_2393463087) on Legal. I don't know if we need to enforce BSO contractually. - [Comment](https://gitlab.com/gitlab-org/gitlab/-/issues/432733#note_1879579003) talks about possible corner cases, in particular [2 owners adding users at the same time](https://gitlab.com/gitlab-org/gitlab/-/issues/444892#note_1802432157) and [delayed invitation acceptance](https://gitlab.com/gitlab-org/gitlab/-/issues/443383#note_1804431949), where even with RA enabled, it would be possible to get into overage state. I think getting into overage state with RA enabled **should not** be possible. What needs to be done to ensure no overages? Or was that problem solved with Phase 2? - What's the currently existing messaging in the GL app? see [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/432733#note_1768774824) and [here](https://gitlab.com/gitlab-org/gitlab/-/issues/432733#note_1800136861) for API messaging. - What should happen in scenario: Customer has 20 seat licence and 20 billable users, they have RA enables. They renew license with 15 seats only. Should we allow for this renewal or should we block it? (can we block a renewal?) - Other scenarios of going to edge cases where going to overage while BSO is enabled were documented in [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/451316). The issue has been closed, but I want to go over those scenarios again, to make sure no overages when BSO are enabled are possible. - How is [Flag in Zuora](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/2388) working now? From [here](https://gitlab.com/gitlab-org/gitlab/-/issues/432733#summary-5): "Create a `contract overages allowed` flag that GitLab controls, which determines if this feature is on or off by default for the customer. This flag would rely on data from Zuora as the SSOT & be driven based on the contract + other conditions." What should be SSOT? I thought FF in GL app, but not thinking flag in Zuora should be SSOT. Looks like initially it was planned that RA would be enforced as part of a customer's contract (see [here](https://gitlab.com/gitlab-org/gitlab/-/issues/483147)). </details> ## Dependencies - Ensure minimal access role is non-billable on Premium and Ultimate tiers ## Rollout Rollout strategies are discussed in separate epic: https://gitlab.com/groups/gitlab-org/-/epics/18788+ ## Success metrics - Measure reduction in billing support tickets - Capture seat purchase conversion rates - If we decide to have a cohort where Restricted Access can be enabled and disabled - measure the rates of feature getting disabled. Previous [Data issue](https://gitlab.com/gitlab-data/product-analytics/-/issues/2103) and [another one](https://gitlab.com/gitlab-data/product-analytics/-/issues/2453#note_2883612867). ## Documentation Update feature documentation throughout development to reflect current capabilities and limitations. --- **Support Priority Score:** 31 <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> > [!important] > > This 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. <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION-->