<!--Please complete the template below as best as you can. Make sure to check if this issue has already been raised by someone else first to avoid duplication. For each section below, please add screenshots or links or anything that may help visual learners understand the problem better, even if this takes you an extra minute or two this is a great help to some folks. https://www.learning-styles-online.com/style/visual-spatial/--> ### Problem As indicated [here](https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/6799#what-are-the-risks), the Support Engineers continue to use Mechanizer to extend subscriptions (instead of the temporary extension tool) due to guardrail restrictions and lack of awareness on the existence of the extension tool among other reasons. This poses as a blocker to deprecate Mechanizer. ### Proposal <!--Consult with `@marc_disabatino-admin` on the customers-gitlab-com~20279829 team if Zuora business logic is involved.--> #### Revised proposal * A Support admin can request an extension by providing the namespace ID and the number of days in a dedicated admin page for this purpose * On submission, the application will check if an expired or active trial exists for the namespace, and if it does, it will redirect the Support admin to edit the trial instead * If no trial exists, the application will generate a temporary extension for the namespace. All guardrails except the duration check will be skipped. The duration guardrail check is the extension cannot be requested 15 days prior or 13 days after the subscription term end date. Multiple extensions can be granted as long as the first extension is requested no later than 13 days after the subscription term ends #### Previous proposal The scope of this issue is to create a Support admin page to generate extensions, which will internally invoke the temporary extension workflow, initially without the guardrail restrictions. The other option discussed was to grant trials. However, using the existing temporary extension solution gives us a few advantages listed below: 1. **SOX compliance:** Audit trail of extensions granted, reason, author, type of subscriptions it was granted to, etc. 2. Segregation of extensions / trials 3. Ease of incorporating guardrail conditions to the workflow as per requirement #### Points to consider 1. We currently restrict one extension per subscription term, while with mechanizer, multiple extensions can be granted. Multiple extensions are currently feature flagged, and this is something that can be enabled based if required 2. Currently, extension can be requested 15 days prior and 13 days after the subscription term ends. Flexibility of the extension period is another aspect present in mechanizer which may require consideration if we want to port it to admin dashboard ### Next steps 1. Consider deprecating the Mechanizer functionality to extend subscriptions **Support Priority Score:** (0, 3, 3, -, -, -, 3, 3, -, -, 2) => 14