needs-orgtag with appropriate organizations
SM with SLAqueue
.com with SLAqueue
needs-orgtag with appropriate organizations
Occasionally tickets come in without an associated organization, which means that no SLA is applied.
Potential reasons this might occur:
It could equally be the case that a ZD organization was manually created and the SLA type is out of date / incorrect. Many of the same principles apply here.
Please do not manually create organizations. This can break the ZD<>SFDC integration and cause users to receive incorrect SLAs. If you notice an organization needs to be created, please notify support-ops to rectify this.
This workflow applies if:
needs-orgis applied (implied by above)
There are two types of users/organizations that have not yet purchased a GitLab subscription/license:
How to define if a ticket is from a prospect or a trial? A long term solution is still in progress. At the moment, the process is mostly manual: check the form content, check the ticket content, it can refer to POC or prospect, check if there were any sales representantives' posts in one of the Support Slack channels. In the last case, please add an internal note on the ticket. Hints mentioned below should help you to identify prospects or trials correctly.
While SFDC syncs organizations nightly to Zendesk, it does not include trial licenses because no organization account is created in SFDC for trials, only a lead. So organizations on a trial will not be shown in Zendesk.
To check if a customer is on a trial: in SFDC (see search instructions below),
Initial Source will likely say
Trial (check that initial date is within
the standard trial period).
For GitLab.com, in the CustomersDot,
trials are marked with an expiration date under the Trials column in the
GitLab Groups Tab next to a namespace.
If needed, also check the
for manual plan changes.
Trial users do not get support as mentioned at Free trial page.
If you find a ticket from the organization using trial, add
trial tag to it.
Once tagged, the ticket from trial
will move to the view
Free/Self-Provisioned Trial Support and will not get SLA.
Note: due to the type of subscription/license they receive, trial users often identify themselves as Ultimate or Gold customers. This form field does not need to be updated as SLA is tied to the Zendesk org.
Prospects will get SLA if the conditions listed in Trials and Prospect Support are met: if an organization in SFDC has
Manual Support Upgrade checked. In this case, an org with
Prospect - CE User will be synced to Zendesk, it will be possible to associate a user with this org,
and their ticket will then get SLA.
Such organization will get SLA because it will have
By default, such tickets will be shown both in SM and GitLab.com views. To make it visible
only in the appropriate view, add either
prospect_sm tag to a ticket.
If the steps described in Trials and Prospect Support
were not done, a prospect organization will not be propagated from SFDC to Zendesk, and the prospect will not get SLA.
In this case, assign
prospect tag to this ticket. It will be moved to the view
Free/Self-Provisioned Trial Support without SLA.
Note: there can be duplicate orgs or orgs incorrectly marked as prospects. If you see that the org is a prospect but other evidence shows that this is a valid customer, follow the workflow Organization is incorrectly marked as a Prospect in SFDC.
In SFDC, you may notice an organization has the Type set to
Prospect but associated with a non Expired support level,
and the account in the CustomersDot shows that the org has a valid self-managed license or a GitLab.com subscription.
In this case, it you may need to update the org in SFDC:
Subscriptionssection in SFDC contains information about a valid subscription and is not empty.
Prospecttype, change it to
@Sales-Supportby following the steps similar to the ones in this section to tag them.
Sales-Supportto do it.
Customertype, it will be propagated to Zendesk.
For GitLab.com, if a user cannot be identified as a customer, nor a
trial or prospect, it should be marked as
Free user. See example below:
firstname.lastname@example.org a ticket to GitLab Support.
email@example.com, the e-mail specified in the field
Email associated with your subscription, or using the customer's domain and you cannot find any related accounts in SFDC.
Choose a plan that suits your needswhen using
In such case, select
Free user in
Tell us about your GitLab subscription dropdown and
submit the ticket to apply the changes. This ticket will now disappear from the
Needs Org & Triage view
and will be visible in
Free/Self-Provisioned Trial Support view.
If you are unsure if a user is really free, ask for someone with admin access on GitLab.com
to check the user via the
#support_gitlab-com Slack channel.
Note: be extra careful when searching using the customer's domain: there can be generic domains that you are not aware of, and there can be large customers with multiple organizations using the same domain. Therefore, search by e-mail is more reliable.
Note: in some cases you will need to search by e-mail and by domain. For example, if the e-mail has previously been associated with a trial account it will still be visible in SFDC but this might not be the same account that is used by the organization.
You may attempt to find the organization within Zendesk using the search functionality. Do note that TLDs don't necessarily correspond to company names, so you may need to search in SFDC to find the appropriate organization.
Also, note that users may be using generic mail providers you might not be familiar with, so the TLD on their email address may not correspond with their company at all.
When in doubt, check SFDC
At times, the organization exists in Zendesk but has the wrong service level. This would indicate a potential problem with the SFDC -> ZD sync, so you should open an issue to the support-ops-project
All self-managed licenses including trial ones should be available in LicenseDot portal. You should be able to access it with your dev.gitlab.org account. If a customer provides you with their license ID, you can verify it in the portal by appending the ID to the link https://license.gitlab.com/licenses/, so the final link to the license will look like https://license.gitlab.com/licenses/LICENSE_ID
Important: Be extra careful here. If a large company has multiple subscriptions it may not be appropriate to add the domain. You'll need to add individual customers to the appropriate organization (see below)
Once you've determined the appropriate domain to add and identified the correct
ZD Organization, you can click the
Domains field to add it.
If you don't have admin access on ZD, you can still make sure the proper SLA is applied by adding the user to the appropriate organization.
Before doing this, you first need to ensure the user is supposed to be associated with the organizations. The current process for this is as follows:
For GitLab.com users:
For Self-managed users:
/admin/licenseendpoint from their instance or to tell you the e-mail to which the license their organisation is using is associated to. To do this quickly, you can use the macro called Self-Managed::Locating GitLab subscription.
#account-managementslack channel and mention the TAM or AM if they are known.
Note: While you are working with the TAM/AM to get the user added as a Salesforce contact, please let the customer know you are reaching out to their TAM/AM to get them properly associated with the organization.
The process to associate a user with an organization is:
When a customer responds to a ticket from an email address that is not included in CC or is not the original requestor, the customer's response is recorded as internal. The current workaround is to add that email of the customer to CC and reply. After that, their next replies will not be marked as internal anymore.
Be sure to notify the customer that a CC has been added to the ticket. For example:
We got a note from John with email address firstname.lastname@example.org. From the context it looks like they should be included in the ticket, so for convenience I added them to the CC list. If they shouldn't be included, please let us know so we can remove them.`
Now that you've added the appropriate domain, head back to your original ticket and verify that it is associated with the appropriate organization and SLA.
Sometimes you may notice that a ticket still has no SLA even when a user is associated with an organization. There are two classes of reasons:
By-default Zendesk behavior:
Org's status on SFDC side:
Statuses of organizations are propagated to Zendesk from SFDC during the regular sync. SLA will not be shown for organizations
with some special statuses. To check the status of an organization in Zendesk, click the organization name and check the field
see the GIF below. The following values of
GitLab Plan may cause the absence of SLA:
Community. It means that the organization is an educational institution that obtained a license according to
GitLab for Education, and this license does not have support included
unless it was purchased additionally. Their tickets will have no SLA, and it is expected behavior. You may explore their
status on the SFDC side according to Finding the existing organization in SFDC.
Expired. In general, it means that their self-managed license or GitLab.com subscription is expired
but often it can be caused by some incorrect information on the SFDC side. Follow the section Handling customers with expired licenses and updating info on SFDC side to fix it,
and then follow the Fixing tags for tickets with
Expired organization section.
Note that we have an ongoing issue
that causes a lot of accounts to be incorrectly shown as
Expired in SFDC. Follow the same workflow to deal with them.
Hold. Such status can be shown if customer delays payment or there is some other issue with the sales process. You may contact an Account Manager or
other person involved in the sales process to clarify the customer's status in such case.
GitLab Plan shows a valid value like
Starter, etc but there is still no SLA then likely there is an issue with tags in the specific ticket. You may explore it on your own or ask support-ops or other support team members for help.
Important: always leave internal comments when doing something on the SFDC side or modifying some tags in Zendesk. It will help next engineer to understand what was done in the ticket.
GitLab Plan in Zendesk shows
Expired, it means that the organization is marked as
Former Customer in SFDC, and support level is set to
Expired there. In such case, it is
better to check with Sales if the status is valid or not:
Show feed button at the upper part of the page.
Send a message there asking to clarify the customer's status and mention
@Sales-Support username in SFDC, they should be able to help with such cases.
Make sure that
@Sales-Support is converted into clickable username, otherwise
Sales Support team will not get your message (see the GIF below):
Example of the message:
John Doe (Support Engineer): @Sales-Support, this organization has Support Level set to Expired, and they opened a new ticket. Can you clarify if the support is really expired and if we should decline support for this customer, or this is some kind of error and Support Level should be updated? Customer also provided screenshot of their license and it seems valid.
Prepending your message with your name and role (e.g.
John Doe (Support Engineer):
helps as everyone in Support is using a shared account so it is not possible to
deduce who sent which message.
Note: the same workflow applies if you notice that customer-related
information is not up-to-date on SFDC side and you are not able to update it
using our generic
Support Admin account.
If data in the LicenseDot and the CustomersDot shows that the customer has a valid license, you should update the ticket in Zendesk side. This part does not overlap with the steps from Handling customers with expired licenses and updating info on SFDC side, it should be done in combination: first update information on the SFDC side to fix future tickets, then follow this section to fix existing tickets:
Tagsfield where all the tags are listed.
Tagsfield. When you see the required tag in the dropdown list, select it.
GitLab Planis shown as Expired.
GitLab Planvalue on Zendesk side will change from
Expiredto the valid one after the sync is done. After that new tickets from this orgination will be shown correctly.
SM with SLAqueue
If you're sure that the ticket is related to GitLab.com, but you see it in SM with SLA queue, do the following:
prospecttag and the following note:
This ticket was in SM with SLA queue, but it's obviously related to GitLab.com. I did not go into details whether this is a paying or free GitLab.com user, I only changed the tags so that it is not listed in the wrong queue, please verify if the customer is paying GitLab.com user and add the necessary tags so that correct SLA policy is applied to the ticket.
.com with SLAqueue
If you're sure that the ticket is related to Self-managed, but you see it in .com with SLA queue, do the following:
prospecttag and the following note:
This ticket was in the
.com with SLAqueue, but I believe it to be related to a Self-managed instance. I have not checked whether this is a paying or free user. I only changed the tags so that it is not listed in the wrong queue. Please verify if the user is a paying Self-managed customer and add the necessary tags so that the correct SLA policy is applied to the ticket.