NOTE: If you are a GitLab team member who wants to file an internal request, please see the Support Internal Requests handbook page.
NOTE: For internal requests relating to licenses and subscriptions, please refer to the relevant license and subscription workflow, or CustomersDot console workflow.
This document details the various templates and workflows that should be followed in order to properly service GitLab.com related requests that Support receives in the internal-requests issue tracker.
Internal requests can and should be addressed by any GitLab Support team member who is able to resolve the request.
Those who are at least 50% SaaS focused and have a GitLab.com administrator account should subscribe to and handle any issue that is an Admin Escalation.
Internal requests are typically created by other team members who are not within the Support organization, but you can always create an internal request to track work being done, especially in cases where the request originates internally (and there is no ZenDesk ticket to track).
At the very least, you should subscribe to the following labels:
You may want to consider subscribing to Platform::SaaS but be aware this will be noisier.
By subscribing to the labels, you'll receive notifications on when a request is created. You should try to work them into your regular workflow, ensuring that you are assigning it to yourself like a customer ticket if you decide to take it.
If you are interested in servicing internal requests that require console access, consider speaking with your manager about completing the Gitlab.com Console module.
For sales assisted trials, only we can override the credit card validation requirement for a namespace. See Internal Requests > SaaS Trial Related > Change an existing SaaS trial plan for instructions on how to perform this task.
Sales team members will typically open this on behalf of their prospects in order to extend an active trial. You can follow the L&R Workflow for Extending Trials.
GitLab Team Members can no longer submit inactive namespace / namesquatting requests for their own use. See: support-team-meta#5170
Customers can submit a support ticket. See Name Squatting Policy.
GitLab team members will use this template to request Support to contact a user on their behalf.
Usually, these are assigned to CMOC, but can also be completed by anyone with admin-level access to GitLab.com.
Admin Escalation label is applied and everyone with admin access is supposed to be subscribed and working on such issues.
See the Sending notices workflow for complete instructions on how to contact users.
At times, users require an increase to the size limit of their repository as a workaround for a bug issue. In these cases:
Repo Size Limitissue template.
Admin escalationlabel. If needed, post in the
#support_gitlab-comSlack channel for attention on it.
Manager Approval::Requiredlabel, and post in the
#spt_managerschannel to request approval.
Status::On Holdlabel and set the due date to when it should be reverted.
See internal wiki page.
This is a generic template used to request an engineer with GitLab.com console access to take action.
Common issues include the following when the UI and API methods are not working:
Rarely, console escalations will also be used to workaround lack of a feature where Support can complete actions that would be unavailable or onerously time-consuming to customers.
Console escalation requests can also serve a purpose when further information (unavailable through the UI or API) is needed to understand the root cause of a problem. For example, searching for unverified secondary email until gitlab#367823 is resolved. This may be because we are not sufficiently logging in Kibana/Sentry, we're unable to replicate an issue, or the creation of an issue may not be the appropriate action needed to resolve a customer problem. Collaborate with console enabled engineers and product teams to solve these types of problems.
Engineers with console access should search for similar previous requests, look for the relevant function in the code, or work with another engineer to resolve each request. Common or custom functions can be found in the support runbooks.
Any request requiring disk access or a big data pull request similar to this example, which cannot be done via rails console, requires an infra issue. Please note that infra does not have an SLO on these requests and may, in the customer's view, take an unreasonable amount of time to action on.