Support Operations has a public form that end-users can use to submit tickets. These go directly to us. Currently, we have 6 problem types:
This is for user's who have not been setup in the support portal previously. Here they should detail what user's they'd like setup and any important details we should note for working with their organization.
There are two types of situations these can involve:
The latter simplifies the process and should mirror Manage my organization's contacts.
To begin with, we will need to have the user prove their support entitlement. To
do this, use the macro
Support::Support Ops::Proof of support entitlement.
Once the user has replied with the requested information, we need to locate them in cDot:
xxxwith the license ID)
If given a license ID).
If given a license ID).
Zuora__Subscriptions__c.NamespaceID__c(see Using workbench for details on doing this)
Note: This can be tricky and some nuisances can occur. If you encounter issues locating an account, please reach out to your fellow Support Operations Specialists for assistance.
After locating them in cDot, click the
Edit tab to go to the customer edit page. On this page, copy the
Salesforce account value. You will then use this to search in Zendesk for the
organization in question (use
salesforce_id:xxx for the 18 character values
sfdc_short_id:xxx for the 15 character values).
Once you have located the organization via search, you can then associate the user to that organization (pending no organization notes specifying otherwise).
After doing so, the process should then mirror Manage my organization's contacts.
To get the namespace ID via ChatOps, DM GitLab ChatOps the following:
/chatops run namespace find PARENT_NAMESPACE
PARENT_NAMESPACE with the parent namespace's path. Running this will
produce results that include the namespace's ID.
To use workbench to locate the Salesforce Account ID:
SELECT Account_ID_18__c, Zuora__SubscriptionStartDate__c, Zuora__SubscriptionEndDate__c, GitLabNamespaceID__c, GitLabNamespaceName__c FROM Zuora__Subscription__c WHERE GitLabNamespaceID__c = 'XXXXX'
XXXXXwith the namespace ID
You might need to review the account in Salesforce specifically to determine if you have the correct one.
This is for user's wishing to setup their organization within the support portal and are not using a contact management project. They should only be coming from users who are already associated to their organization. If they are not associated, please see First time setup.
Add useroption. A pop-up modal will appear asking for the name and email of the new user. Enter the relevant information and click the blue
User typewill always be
Userstab on the organization page or via search). From there:
User was de-associated from the organization as per TICKET_LINK
TICKET_LINKwith the link to the request.
After doing the above, you need to reply to the requester confirming the state of their request. To assist in this process, we have some macros you can use:
Support::Support Ops::Users added to organization
Support::Support Ops::Users removed from organization
Support::Support Ops::User has non-closed tickets
Support::Support Ops::Users need to perform password reset
These can be used in combination of one another, as they are not full response macros (but instead pieces of a full response).
When a organization not using a contact management project exceeds 30 support contacts (or a request to add more contacts would do so), we need to intervene to address that issue. For these types of issues:
Support::Support Ops::Maximum contacts reached. This will require you to attach a CSV of the current contact list for the organization. To get a CSV:
Userstab, enter the organization's ID in the
Organizationfield, then click the blue
Columnsand deselect all checkboxes except for
Download CSVbutton and wait for the download to complete
Remember, once the maximum contacts limit issue is fixed, you might need to review the ticket and go back to a previous issue that the ticket was raised about.
These are requests for shared organization setup/management. See the Shared Organizations workflow for more details.
These requests are a bit more complicated to do. Please see Contact management projects for more information on doing these.
These are were general questions about the support portal should go. Do your best to answer the questions presented in a timely manner.
These are reports of issues within the support portal. While each issue can present unique challenges, the common troubleshooting guide for these would be:
[*.]gitlab.com* Ask the user to confirm they have deleted all cookies and cache (and re-logged in). * Ask the user for the browser type being used. * Ask the user for the browser version being used. * Ask the user for a list of browser plugins being used. * Ask the user for a list of browser themese being used. * Ask the user for a list of browser extensions being used. * Ask the user for the JS Console output. * Ask the user for a HAR file.
This is a catchall field, meaning there is no specific workflow for requests using this problem type.
When a ticket is filed using the incorrect form, agents will use the
General::Forms::Incorrect form used macro. This will change the form to our
form, tag the ticket, and leave an internal note. From there, we are expected
to review the ticket and resolve the problem.
To do this, the best approach is often to create a new ticket for the customer using the correct form. When doing this, review the original ticket to best determine which form to use (if you are unsure, reach out to a Support Manager or Support Ops Manager for assistance).
Once you determine the correct form, you should review what ticket fields that form uses and what information is missing. In the original ticket, leave an internal comment saying which form needed to be used and what data is missing. Any of the data you can determine based on the original ticket is a plus, as it will skip needing to ask the customer to reply with that information in the new ticket. An example note could be:
The correct form should have been Self-Managed.
The missing data is:
- Self-Managed Problem Type
- GitLab Install Type
- GitLab Version
Once you have noted the original ticket, create the new ticket using the correct ticket form. Make sure to file the ticket using https://support.gitlab.com/hc/en-us/requests/new (you may need to use a different browser or an incognito window) so the first reply is from the original requester and not an agent (this ensures it gets the FRT SLA). Make sure to fill in as much of the information as is possible. For any information you do not readily know, do your best to guess for the time being.
Some notes to help in filing the ticket properly:
Recently you filed ticket #
with us. Sadly, it was using the incorrect form and was filed incorrectly on our end. To help clear that up and get you working with the correct team, we are filing this new ticket on your behalf.
During our review of ticket #
, we did find some needed information was missing. Please comment back as soon as possible with the following information: While we review your ticket, here is some other data you could also send that is often helpful to us: * A GitLabSOS report (https://gitlab.com/gitlab-com/support/toolbox/gitlabsos/) if you are using Omnibus * A KubeSOS report (https://gitlab.com/gitlab-com/support/toolbox/kubesos/) if you are using Kubernetes Your original request's ticket description was as follows:
Once the new ticket is created, notate the original ticket and send a reply using the
Support::Support-Ops::Response to original ticket using an incorrect form macro.