Confirmation Emails

1. You are here:
2. Handbook
3. Support Team Handbook
4. Support Workflows
5. Confirmation Emails

On this page

• Overview
• Triage the ticket with the correct problem type
• Check GitLab User Lookup App
• Check GitLab Admin
  • Fix Email Address
• Removing a Suppression in Zendesk
• Check Mailgun
  • Removing a Suppression in Mailgun
  • Identifying Multiple Suppressions on a Single Domain
• Resend Confirmation Email
• Primary email
• Secondary email
• Wacky state

Overview

This workflow covers cases when a user says they are not receiving their confirmation email.

The activation token in a confirmation email will only be valid for 24 hours. Thereafter, the user will need a new confirmation email.

Triage the ticket with the correct problem type

Make sure that the ticket is correctly triaged with the Did not receive confirmation email problem type, so that the SaaS Account Ticket Helper can activate.

If the user has already correctly chosen the problem type, the automation will activate when an agent opens the ticket for the first time.

Check GitLab User Lookup App

1. Click the Apps button located in the top right of the Zendesk interface.
2. Scroll down to the GitLab User Lookup app.
3. Check if the app found any account associated with the username/email provided by the user.
   • No account? Use the Zendesk macro Support::SaaS::Account does not exist or if you believe it's applicable use General::Verify self-managed or .com.
4. If the app returns a result for the username lookup, but no result for the email lookup, go to their provided Admin Link and check what email address the user has on their account. Continue on to Step 2 under Check GitLab Admin

Check GitLab Admin

1. In the GitLab.com Admin Area, search for the user by username or email address to confirm the account has been created. Alternatively, search in your browser using the API (or through chatop).
2. Check the email address against what the user has reported.
   • Did they make a typo when registering? See Fix Email Address.
   • Otherwise see Removing a Suppression in Zendesk.

Fix Email Address

If the user made a typo:

1. Make sure the account in question has no activity by checking the following fields are blank/nil:
   • Confirmed At
   • Last Login
   • Last Active At
2. Edit the email address so that it is the correct one using one of the following methods:
   • Admin: when viewing the user in admin, click on Edit, then Save when done.
   • Chatops
     • View User: /chatops run user find <user or email>
     • Edit Email: /chatops run user update_email <username or current email> <new_eamil@example.com>
3. Ensure that it now shows the new email.

Removing a Suppression in Zendesk

1. Click the Apps button located in the top right of the Zendesk interface.
2. Scroll down to the SaaS Account Ticket Helper app located below the tag locker app.
3. Click the button for Email Suppressions.
4. Search for the email address using the search field.
5. If a suppression is found you may optionally click the copy button to save the log from Mailgun to your clipboard that you can then paste into an internal comment on the ticket.
6. Click the Remove the suppression? button.

Once the suppression is removed you can then use the quick links menu that is displayed to either resend a new confirmation email, send a password reset email, or perform another search.

Check Mailgun

On the first attempt, if our email system could not get through (usually server says it's non-existent or similar), then our mail server will put a suppression on sending further emails.

This is useful to check if emails have been delivered successfully from our end, which could mean that the error is with the users' email provider.

1. Log in to Mailgun using the supporteam credentials in the Support Team vault in 1Password.
2. Click on Sending along the left-hand side navigation bar.
3. Click on Logs.
4. Ensure that mg.gitlab.com is set as the domain above the activity graph.
5. Enter the email address to be checked into the search bar, search, and then scan the results to see if mail is being delivered to that address.
   • If email is delayed, respond to the user and ask them to wait.
   • If email is bouncing due to a suppression (evidenced by the message Not delivering to previously bounced address in the log) proceed to Removing a Suppression in Zendesk or Removing a Suppression in Mailgun.

Removing a Suppression in Mailgun

If the SaaS Account Ticket Helper doesn't work for any reason, we can remove suppressions in Mailgun directly:

1. Click on Suppressions along the left-hand side navigation bar.
2. Wait a moment for results to load before searching.
3. Ensure that mg.gitlab.com is set as the domain at the top of the page.
4. Enter the email address to be checked into the Search for recipients search bar and perform a search.
5. Click the Delete button next to an entry and then confirm your selection to remove the suppression.

Identifying Multiple Suppressions on a Single Domain

Mailgun does not allow us to check for multiple suppressions on the same domain within it's Suppressions section, but we can use another method to find them without asking the customer for a list of email addresses that they suspect are being suppressed. To do so:

1. Log in to Mailgun using the supporteam credentials in the Support Team vault in 1Password.
2. Click on Sending along the left-hand side navigation bar.
3. Click on Logs.
4. Ensure that mg.gitlab.com is set as the domain above the activity graph.
5. In the search bar enter the customer's domain using * as a wildcard for the username.
6. Add a filter for Event is Permanent Fail.
7. Scan the results, any email address listed with a Delivery Status Message of Not delivering to previously bounced address has been suppressed at one point in time.
8. Navigate to the Suppressions tab and enter in an email address from your previous search to confirm whether or not it's currently suppressed.

Resend Confirmation Email

Primary email

Once the problem has been fixed, you can send the user a new confirmation email if it's the primary email address.

Let the user know you've sent a new confirmation email and ask them to check their inbox and spam folders.

Note: If a user changes their primary email, the form will also not work and they have to follow the process below for secondary email.

Secondary email

Instruct the user to sign in and trigger a new confirmation email through their profile: https://gitlab.com/profile/emails

Wacky state

If the user is unconfirmed, but their primary email address does not match the unconfirmed email address (see this internal example), then two options:

1. Impersonate the user and click on the "Resend confirmation email" under Email on their Settings > Profile page.
2. File a console escalation internal request to set the unconfirmed_email to nil.