<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=473020) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=473020) </details> <!--IssueSummary end--> ### Context In https://gitlab.com/gitlab-org/gitlab/-/issues/455903+ we will add placeholder user limits for top-level groups based on tier and seat count, on .com. We might need a possibility to adjust those limits for chosen top-level groups on .com, in case a customer would require more placeholder users to successfully complete their migration. The assumption regarding the number of necessary placeholders might not be true for all customers. If necessary, the customers should be able to request the limit to be increased on .com for their top-level group, via Support, their CSMs. ### Proposed solution Investigation was done in https://gitlab.com/gitlab-org/gitlab/-/issues/455904+. 1. We need two solutions/mechanisms for .com: * limits based on group's tier and seat number (done in https://gitlab.com/gitlab-org/gitlab/-/issues/455903+) * possibility of raising the limit for a chosen top-level group by an instance Admin (this issue). Add the input field to the `/admin/groups/:id` form BEFORE COMPUTE QUOTA:  The hint text below the limit inbox should be "Maximum number of allowed [placeholder users](link to placeholder documentation) in group." Upper most limit for a top-level group, that an Admin can set up is 15000. To know who made the change and when, we should create an [instance audit event](https://docs.gitlab.com/ee/administration/audit_event_reports.html#instance-audit-events). UI and docs: Place a general warning before the beginning of migration about the limited amount of placeholder users per top-level group with a link to docs, where limits are listed. Customers should familiarise themselves with the limits and in case customer suspects that they would hit the limit, they could contact their CSM or Support. [Here we're missing the copy of the text that should be added to waring shown before the beginning of migration]. We then need to tweak the logic of the placeholder limit code to factor in this override - see https://gitlab.com/gitlab-org/gitlab/-/issues/473020#note_2004655766.