Skip to content

[SaaS] Modal that informs users of additional charges before adding a member

Problem to solve

SaaS customers are being surprised and taken off-guard by Quarterly Subscription reconciliations. Because self-service SaaS customers have not historically been charged true-ups, the QSR process and the fact that they have to pay for overages is totally new. See tickets from customers here.

Intended users

  • Group Owner or project Owner / Maintainer who adds additional members to a subscription, increasing the seat count
  • Only groups enrolled in quarterly subscription reconciliation. See exactly which use cases we're solving for in the Epic description.

Proposal

When a Member or Group is being added that would increase the subscription's Seats owed number, show a second modal and ask the user to confirm that this action will result in additional charges before actually adding the Member.

Some tricky use cases to keep in mind:

  • If the user (or users in a Group) being added as a Member(s) is already occupying a seat in the subscription, then the modal should not be shown
  • If on Ultimate, guest users should not trigger the modal because guest users do not occupy a seat
  • If the Member is being invited via email (not GitLab username) and that email address is not already occupying a seat in the subscription, then the modal should be shown. The Member being invited will not actually occupy a seat until they accept the invitation from their email (pending members don't occupy seats), but once they do accept the invitation they would occupy a seat immediately, so the user inviting them should be warned that they are taking an action that will trigger an overage.
Some examples of when the modal would and wouldn't be shown

Imagine that Acme Corp is your top level group. You invite Group A to Project 1. Let's assume that I have already exceeded my seat count (I'm at 12/10 seats in use).

  • If the members of Group A are already a part of Acme Corp, then it would not increase the seats owed number and the modal wouldn't be shown.
  • If the members of Group A were not already a part of Acme Corp, then the modal would be shown as the seats owed number would be increased.
  • Another possible situation is that part of the members of Group A are part of Acme Corp and part of the members are not. In this case, the modal would be shown because the members of Group A who are not currently a part of Acme Corp would increase the number of seats owed.

Design

Design here

When the modal that informs users of additional charges is shown, we should have a smooth transition in between the two modals. See the prototype below for details of that interaction.

If inviting user WILL NOT increase the number of seats owed If inviting user WILL increase the number of seats owed
Prototype link
Kapture_2022-01-27_at_11.57.09
Prototype link
Kapture_2022-01-27_at_11.56.39

Note from @esybrant: There are no changes to the Invite members modal. Any differences you see in the prototype are just because I had to recreate that modal in Figma to make the prototype.

Implementation plan

Step Status
Add a modal for user addition window behind a feature toggle frontend !79644 (merged) workflowstaging
Set the transition between two components frontend !80187 (merged) workflowin review
Calculate conditions when we should show a modal backend !78287 (merged) workflowin review
Add a overage check on inviting a group frontend backend !81039 (merged) workflowin dev
Rollout the feature flag #350265 (closed) workflowblocked

List of cases when we show/hide overage modal

Case Is it implemented?
Show overage when added users increase seats_owed !80187 (merged)
Show overage for users added by id and by email !80187 (merged)
Exclude already billed users from overage check !80187 (merged)
Don't show overage on free plans !80187 (merged)
Show overage for groups addition !81039 (merged)
Don't show overage if a group is not included into reconciliations MR TBD
Don't show overage when adding guests to Ultimate group MR TBD

This work was partially started in this issue over a year ago. See comment here for status of work completed and work still pending, we may be able to use some of the completed work.

Edited by Diana Zubova