Confirmation Emails
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.
Stage 0: Ticket Triage
Before working the ticket ensure that it’s correctly triaged with the SaaS Account
form and Did not receive confirmation email
problem type so that
the SaaS Account Ticket Helper application 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. If the SaaS Account Ticket Helper application fails to solve the issue for any reason, proceed to manually resolve it by going through the steps in the following sections.
Stage 1: Locate Account
Before the issue can be resolved we first need to locate the account in question. This can be done by either checking the GitLab User Lookup App or by checking GitLab Admin.
Check GitLab User Lookup App
- Click the
Apps
button located in the top right of the Zendesk interface, while viewing the ticket. - Scroll down to the
GitLab User Lookup
app. - Observe the results. Check if the app found an account associated with the username or email address provided by the user. If a result was returned for the username lookup only, go to the provided
Admin Link
and check what email address is listed on the account. - Proceed to Step 2 under Check GitLab Admin.
If no account was found use the Zendesk macro Support::SaaS::Account does not exist
or, if you believe it’s applicable, use General::Verify account self-managed or .com
and then wait for a followup from the user.
Check GitLab Admin
- In the GitLab SaaS Admin Area, search for the user by username to confirm the account exists. Alternatively, search in your browser using the API or ChatOps.
- Check the email address against what the user has reported and then perform one of the following fixes:
- Did they make a typo when registering? See 👉 Typo Fix.
- Otherwise, they likely are not receiving their confirmation email due to a suppression. See 👉 Removing a Suppression in Zendesk or Removing a Suppression in Mailgun.
Stage 2: Fix
Typo Fix
- Ensure the user is a customer with a current paid subscription. (Do not modify free user accounts. Free users must create new accounts with the correct email address)
- Ensure the user’s account has no activity by checking that the
Confirmed at:
field is blank/nil. - Ensure the user’s account has no group or project memberships. If the account does have group or project memberships, then the user must pass the Account Ownership Verification workflow before proceding any further.
- Change the email address to the correct one using one of the following methods:
- Admin:
- Pull up the user’s account while logged in with your admin account.
- Click
Edit
. - Change the email address.
- Click
Save changes
when done. - Remove the old mistyped email address from the account which will have been made a secondary email address on the account by clicking the red X next to it.
- ChatOps:
- View User:
/chatops run user find <user or email>
- Edit Email:
/chatops run user update_email <username or current email> <new_email@example.com>
- View User:
- Admin:
- Double check that the account now has the proper email address as its primary.
- Add an admin note to the account.
Removing a Suppression in Zendesk
- Click the
Apps
button located in the top right of the Zendesk interface. - Scroll down to the
SaaS Account Ticket Helper
app located below the tag locker app. - Click the button for
Email Suppressions
. - Search for the email address using the search field.
- 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. - Click the
Remove the suppression?
button. - Send the user a new confirmation email.
If this process doesn’t work you’ll need to remove the suppression in Mailgun. See 👉 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:
- Click on
Suppressions
along the left-hand side navigation bar. - Wait a moment for results to load before searching.
- Ensure that
mg.gitlab.com
is set as the domain at the top of the page. - Enter the email address to be checked into the
Search for recipients
search bar and perform a search. - Click the
Delete
button next to an entry and then confirm your selection to remove the suppression. - Send the user a new confirmation email. See 👉 Resend Confirmation Email.
Stage 3: Resend Confirmation Email
Primary email
Once the problem has been fixed, if the email is the primary email on the account, you can send the user a new confirmation email. Afterwards, let the user know you’ve sent them a new confirmation email and ask them to check their inbox and spam folders.
Note: If a user changes their primary email this will not work. See 👉 Secondary Email.
Secondary email
Instruct the user to sign in and trigger a new confirmation email through their profile by visiting 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 there are two options to resolve:
- Impersonate the user and click on the “Resend confirmation email” under Email on their Settings > Profile page.
- File a console escalation internal request to set the
unconfirmed_email
tonil
.
Extras
Checking 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.
- Utilize the Mailgun SSO app on your Okta dashboard to log in to Mailgun.
- Click on
Sending
along the left-hand side navigation bar. - Click on
Logs
. - Ensure that
mg.gitlab.com
is set as the domain above the activity graph. - 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. - If email is marked as
Delivered
and the response code underdelivery-status
is"code": 250
, this indicates that the user’s mail server acknowledged the receipt, and the email delivery was successful.
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:
- Utilize the Mailgun SSO app on your Okta dashboard to log in to Mailgun.
- Click on
Sending
along the left-hand side navigation bar. - Click on
Logs
. - Ensure that
mg.gitlab.com
is set as the domain above the activity graph. - In the search bar enter the customer’s domain using
*
as a wildcard for the username. - Add a filter for
Event is Permanent Fail
. - Scan the results, any email address listed with a
Delivery Status Message
ofNot delivering to previously bounced address
has been suppressed at one point in time. - Navigate to the
Suppressions
tab and enter in an email address from your previous search to confirm whether or not it’s currently suppressed.
f348e5a6
)