This training material will cover the following topics:
As per Zendesk:
Email is one way that end-users can submit tickets to Zendesk Support and have conversations with agents to resolve their issues.
Basically, Zendesk emails enable an end-user to email an address and have a ticket created from it. Usage of this varies widely from instance to instance.
Note: As of 2021-09-21, Zendesk has changed the location of the Emails
management pages. They are now located in the Admin Center, which you can
locate by clicking the four squares in the top-right of the page and clicking
the Admin Center link. After doing so, you can locate the Emails management
pages under Channels > Talk and email > Email. Once you access the
management pages, the steps to create/edit/etc. are the same.
Note: While you can connect external email addresses to Zendesk, we do not do this at GitLab. Instead, we create Zendesk email addresses and have the GitLab email group forward to said Zendesk email address.
To create a Zendesk email, you first need to go to the Admin Center, which you
can locate by clicking the four squares in the top-right of the page and
clicking the Admin Center link. After doing so, you can locate the Emails
management pages under Channels > Talk and email > Email.
You will then click Add address on the top-right of the page. This will have a
dropdown appear. In this dropdown, click Create new Zendesk address. A pop-up
box will appear asking you to enter the username for the address. This should
match the username of the GitLab email address exactly (this avoids a lot of
confusion).
After doing this, click the black Create now button.
Note: This does not create the GitLab email address. To have that done, you will need to file an Access Request issue to have it created. Make sure in the issue to specify the Zendesk email address to forward the emails to.
Note: As of 2021-09-21, Zendesk has changed the location of the Emails
management pages. They are now located in the Admin Center, which you can
locate by clicking the four squares in the top-right of the page and clicking
the Admin Center link. After doing so, you can locate the Emails management
pages under Channels > Talk and email > Email. Once you access the
management pages, the steps to create/edit/etc. are the same.
Note: You can only edit the name of a Zendesk email after creation. If you need to change the address, you will need to delete the existing one and create a whole new one.
To edit a Zendesk email, you first need to go to the Admin Center, which you
can locate by clicking the four squares in the top-right of the page and
clicking the Admin Center link. After doing so, you can locate the Emails
management pages under Channels > Talk and email > Email.
From here, locate the email address you wish to edit and then click the edit
link on the right-hand side of the email address. Doing so will make a pop-up
box appear.
Here, you can edit the name of the address.
Note: As of 2021-09-21, Zendesk has changed the location of the Emails
management pages. They are now located in the Admin Center, which you can
locate by clicking the four squares in the top-right of the page and clicking
the Admin Center link. After doing so, you can locate the Emails management
pages under Channels > Talk and email > Email. Once you access the
management pages, the steps to create/edit/etc. are the same.
Warning! This can be disastrous and can cause issues. Only do this when you are 110% sure this needs to be done. An unused email address is annoying but safe. A deleted email address that was in use causes many issues!
To delete a Zendesk email, you first need to go to the Admin Center, which you
can locate by clicking the four squares in the top-right of the page and
clicking the Admin Center link. After doing so, you can locate the Emails
management pages under Channels > Talk and email > Email.
From here, locate the email address you wish to delete, hover over it, and then
click the delete link.
link on the right-hand side of the email address. Doing so will make a pop-up
box appear. A pop-up box will appear asking you to confirm the deletion. Click
the black Delete address button to confirm.
Note: While the above video is for Zendesk Automations, the exact same process applies for Zendesk Emails. The sole difference in the tags used on the requests and merge requests (if any).
To ensure each runs smoothly, we do our changes in set stages.
All Zendesk email changes should start with a request issue. This issue should stem from a support-team-meta issue (or similar issue) where the proposal was discussed.
The request should not be "make this change in Zendesk," unless the request is coming directly from a Support Ops team member. If the request does not detail what the desired effect is, we as Support Ops should instead push back on the request and ask the requester detail what they want to see as a result and not what they want done in Zendesk.
All request issues should contain the following labels at creation:
While we have scripting and templating in place to find when these are missing, you should strive to ensure those are present. If you find any of them missing, please add them.
Once the request is in good standing, you may assign it to yourself (if it is not already) and add the tag "SupportOps::Doing" to indicate you have started working on this.
When making a change to Zendesk emails (whether it be creation, editing, or deactivation), we start the process in the Zendesk sandbox. In the Zendesk sandbox for the corresponding Zendesk instance this impacts, you will make the desired changes. Once this is done, update the original request issue with the following:
/spend X minutes, where X is the number of
minutes you spent.You will then test these changes. This process should take no less than 3 days after making the changes. This is to ensure that not only is the change tested thoroughly, but others have time to review your tests and the results.
Often, you will need assistance testing out changes. Should this be required, consider reaching out to the following for assistance in testing the changes:
If testing provides failed results, this means we need to update the original request issue with what happened and why. If this is because of a flaw in the request, we should state as much and recommend the requester go back to the original support-team-meta issue to re-discuss. If it failed due to our implementation, we should detail what was wrong with the implementation and propose a new method to try.
Once the changes have been thoroughly tested (and are successful), make sure to add the time you spent doing the testing to the original request.
At that juncture, update the issue with a comment to state testing has completed and was successful. You should give the requester an opportunity to review the test(s) and result(s). Ask if they would like to review them. If they decline, you may move on. If they wish to do so, await their update after they have reviewed the results.
To prepare for the implementation, you may need to create a merge request to the corresponding zendesk-triggers repo. For more info on that, see the Zendesk Triggers training doc.
After creating the merge request, make sure it is linked in the original request and you have added any additional time spent to the requester issue.
From here, have one of your fellow Support Ops team members or a Support Ops Manager review the merge request and add their approval (or comments). Once approval has been added, an implementation date can be determined.
Note: All merge requests in the zendesk-triggers repo should contain the following labels (the same as with issues):
Once an implementation date has been determined, you need to announce this
upcoming change. To do this, go to the Slack channel
#support_ops-accouncements and click the lightning bolt on the text box (this
is the shortcuts icon). From there, select Support Ops Announcement. This
will cause a form to pop-up. Fill out the form to generate a message in the
#support_ops-accouncements channel.
The form asks for the following:
Once it posts, you will need to screenshot the post message and add that to the
Support Operations Corner of the
Support Week in Review
document
After adding it in the Support Week in Review, you then want to cross-link (copy the link to the post) the announcement to the following channels:
| Channel | When to cross-link |
|---|---|
#support_operations |
Every time |
#support_team-chat |
If this impacts Support only or Everyone |
#spt_managers |
If this impacts Support only or Everyone |
#whats-happening-at-gitlab |
If the change is concerning SLA OR provisioning/deprovisioning |
In this stage, you will make the changes in the production Zendesk and merge any related MRs.
Once an implementation has been completed, you need to announce the change. To
do this, go to the Slack channel #support_ops-accouncements and click the
lightning bolt on the text box (this is the shortcuts icon). From there, select
Support Ops Announcement. This will cause a form to pop-up. Fill out the form
to generate a message in the #support_ops-accouncements channel.
The form asks for the following:
Once it posts, you will need to screenshot the post message and add that to the
Support Operations Corner of the
Support Week in Review
document
After adding it in the Support Week in Review, you then want to cross-link (copy the link to the post) the announcement to the following channels:
| Channel | When to cross-link |
|---|---|
#support_operations |
Every time |
#support_team-chat |
If this impacts Support only or Everyone |
#spt_managers |
If this impacts Support only or Everyone |
#whats-happening-at-gitlab |
If the change is concerning SLA OR provisioning/deprovisioning |