## Summary The [Mechanizer](https://gitlab.com/gitlab-com/support/toolbox/mechanizer) is a separate application that enables the Support Team to update data that's not readily accessible via the Customers Admin Portal. Various [Support workflows](https://about.gitlab.com/handbook/support/license-and-renewals/workflows/customersdot/mechanizer/) depend on Mechanizer to complete tasks and serve customers and internal teams efficiently. ### Cost of mechanizer [This thread](https://gitlab.com/groups/gitlab-org/-/epics/6828#note_1230510840 "Migrate Features of Mechanizer Tool to CustomersDot") proves insight into time, code, effort and costs have gone into creating and maintaining Mechanizer. ### Mechanizer Flow In brief, here's the different parts and how it fits into the flow. 1. Support team member fills out a form in [ZenDesk app](https://gitlab.com/gitlab-com/support/support-ops/zendesk-global/zendesk-apps/mechanizer) 2. Completed form gets sent to [Mechanizer](https://gitlab.com/gitlab-com/support/toolbox/mechanizer) 3. Mechanizer runs a pipeline which runs [the relevant console function](https://gitlab.com/gitlab-com/support/toolbox/console-training-wheels/-/blob/master/lib/support_team.rb) ## Proposals To consolidate and create a better and more efficient user experience for the support team, we will audit the features within the mechanizer, identify the problems it helps solve and create a plan to migrate them over to CustomersDot or to eliminate the need for the use of the mechanizer functions. This epic will track the deliverables for this initiative. We will tackle this problem by looking at both short-term and long-term solutions: ### Long-term strategy In the long-term, the goal is to eliminate the need for the functionality that mechanizer was providing by solving for the underlying problems via self-serve features in the product, enabling internal teams with features specific to their workflows (example: temporary license generation for the sales org), and automation. For this effort, we will start by identifying the 3 most used mechanizer functions, which are: 1. https://gitlab.com/groups/gitlab-org/-/epics/8423+ 2. https://gitlab.com/groups/gitlab-org/-/epics/8425+ 3. https://gitlab.com/groups/gitlab-org/-/epics/8424+ We will review each function to determine context for their usage and break this down into separate, specific use cases. So far, we have identified 9 unique use cases, which could each have their own specific solutions. This proposal requires collaboration with other teams; each solution will be tracked separately. ### Short-term strategy In the short-term, our goal is to remove the burden of maintaining mechanizer from the support team in order to minimize further sunken costs. To this end, we will build needed controls in our internal customers.gitlab.com (customersdot) application which will be used instead of mechanizer. As we build controls in customersdot, we can deprecate that functionality in mechanizer. The needed controls focus on namespaces with a trial and namespaces with a subscription. More information on the controls can be found in the related epic: 1. https://gitlab.com/groups/gitlab-org/-/epics/9451+ 2. https://gitlab.com/groups/gitlab-org/-/epics/9453+ This proposal is the top priority for the \~"group::admin tooling" team; these features will be built as soon as engineering capacity is available. ## Support Team Contacts As the main thing that needs to be migrated is the functionality powered by the console functions, your Support DRI is someone who is familiar with the console functions and requirements of the Support team. - Primary DRI: @kevenhughes - Secondary/backup DRI: @cynthia - Mechanizer DRI: @duncan_harris - Support Manager: @ralfaro --- **Support Priority Score:** 19