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)
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.
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 ZD org.
When applicable, tickets should have one of the following tag (not both):
A long term solution is still being worked on, but in the short term, prospects
are supposed to email Support using the email address provided to them or use
the appropriate form field, which will automatically add the
Otherwise, prospects are identified manually either through form content, ticket content, or the sales rep posts about it in one of the Support Slack channels. In the last case, please add an internal note on the ticket.
You can manually add the appropriate tag to the ticket. To do it, start typing tag name in
Tags field, add the tag and Submit the ticket to add the needed tag.
Once tagged, the ticket will move to the appropriate queue, and for prospects, with appropriate SLA. However, trials do not receive support (wording included in our "free user" macro), and prospect SLA is for guidance only.
While SFDC syncs organizations nightly to ZD, it does not include trial licenses because no organization account is created in SFDC, only a lead. So organizations on a trial will not show in ZD, and this workflow does not apply and we should not manually create these organizations.
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 prospects, there will likely be an organization account with
Prospect. However, the presence of an org with type prospect does not mean
they receive pre-sales support.
For self-managed, you can double-check for a license in the
You should be able to access it with your
For GitLab.com, in the Customers Portal, 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.
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
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:
/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:
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 license app and the customer portal 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.
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 Customer Portal 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 on their own.
Customertype, it will be propagated to Zendesk.