Iteration 1: Improve error state for .com Group Owners without access to the Billing Account

Problem

GitLab group Owners on SaaS who are not a Billing Account Manager for their group's main product subscription hit confusing, dead-end errors when they are redirected to the Customers Portal to manage their subscription.

Two commonly reported examples, both triggered from the GitLab Credits Dashboard on GitLab.com:

Example A - Accepting on-demand billing

  1. Group Owner clicks "Accept on-demand billing" on the GitLab Credits Dashboard
  2. Gets redirected to customers.gitlab.com/subscriptions/SUBSCRIPTION-NAME/usage
  3. Logs in to the Customers Portal
  4. Gets redirected back to customers.gitlab.com/subscriptions/SUBSCRIPTION-NAME/usage with a 404 error — because they are not a member of the Billing Account for that subscription

Example B - Purchasing a Monthly Commitment

  1. Group Owner clicks "Purchase Monthly Commitment" on the GitLab Credits Dashboard
  2. Gets redirected to customers.gitlab.com/subscriptions/purchase/new?gl_namespace_id=GROUP-ID&product_rate_plan_id=...&subscription_name=SUBSCRIPTION-NAME
  3. Logs in to the Customers Portal
  4. Sees "GitLab Credits - Monthly Committed Pool requires a subscription" — because they are not a member of the Billing Account for that subscription

In both cases, there is no explanation of why the error is occurring and no guidance on what the user should do next.

Impacted customer cohorts

The group Owner hitting these errors can belong to one of two cohorts, each with a different resolution path:

  1. Group Owner with no existing Billing Account — can be added to the Billing Account for the subscription directly.
  2. Group Owner who already belongs to a different Billing Account (e.g., previously purchased an add-on for that group) — cannot be added to a second Billing Account until gitlab-org#8986 is complete; must first be removed from their existing Billing Account.

Proposal

For both scenarios, replace the dead-end error with a clear, contextual message that:

  • Explains that access is blocked because the user has not been added as a Billing Account Manager for this subscription
  • Instructs them to contact their Billing Account Manager to request access
  • Provides a fallback to GitLab Support if they are unable to reach their Billing Account Manager

Where possible, the message should acknowledge which cohort the user belongs to:

  • If they have no existing Billing Account — reassure them that joining is straightforward once a BAM adds them
  • If they already belong to a different Billing Account — set expectations that resolving this is more involved, and direct them to GitLab Support

Proposed messages to show to the customer

Cohort 1 - Group Owner with no existing Billing Account

No billing account access

You're signed in as a GitLab group Owner, but you don't have access to manage the billing account for this subscription. Contact your billing account manager and ask them to invite you as a billing account manager for full access. Need help identifying who manages billing? Check with your organization's finance team or the person who originally purchased your GitLab subscription.

Cohort 2 - Group Owner already belonging to a different Billing Account

No billing account access

You're signed in as a GitLab group Owner, but you don't have access to manage the billing account for this subscription. Because you're already a member of another billing account, gaining access requires additional steps. Please contact GitLab Support for assistance.

Open Questions

  1. Can we identify the Billing Account Manager at the point the user sees the error? If so, surfacing their name or email in the message would make it significantly more actionable
  2. Can we detect which cohort the user belongs to (no billing account vs. already on a different one) in order to tailor the message appropriately?
Edited by Tatyana Golubeva