--- module-name: "GitLab-com SaaS Account Basics" area: "Customer Service" maintainers: - tloughlin product_category: "GitLab.com (SaaS)" --- ## Introduction This training module focuses on the basics of GitLab.com (SaaS) account related knowledge for both new and existing Support team members. ### Goals At the end of this module, you should be able to: - have awareness of common SaaS Account requests - work SaaS Account tickets ### General Timeline and Expectations - This module is a combination of reading material and working on tickets. - This module's material and ticket work should take you 4 days to complete. - Read about our [Support Onboarding process](https://handbook.gitlab.com/handbook/support/training/), the page also shows you the modules under the GitLab.com SaaS Support Basics Pathway. ## Stage 0: Create Your Module 1. [x] Create an issue using this template by making the Issue Title: `<module title> - <your name>`. 2. [x] Add yourself and your trainer (if applicable) as the assignees. 3. [x] Set milestones, if applicable, and a due date to help motivate yourself! ## Stage 1: GitLab.com Admin Access > [!note] > > Keep in mind that only GitLab team members are admins, and that accounts are bound by our Terms of Use as covered [in the overview](https://handbook.gitlab.com/handbook/support/workflows/gitlab-com_overview/). > > **_Bottom Line_**: Never share information that a user would not have access to even if it's about another user within their organization, except for Enterprise Users. You can still suggest possible solutions based on the description of the problem (and even what you find out about the account), but definitive information cannot be shared. 1. [ ] **Request your admin access** - [x] Speak to your manager to seek approval for requesting an Admin account to begin handling SaaS Account tickets. - [ ] **With manager approval:** Complete [GitLab.com Admin access Training Module](https://gitlab.com/gitlab-com/support/support-training/-/issues/new?issuable_template=GitLab-com%20Admin). Whilst you await for your Admin account to be provisioned, you can continue with Stage 3 ## Stage 2: Confirm Your Accounts At this stage, you should have 3 different GitLab.com accounts. 1. [x] Your user account you received on day 1 - `username`, `username@gitlab.com` 2. [x] Your Auditor (read-only) account that was set up during your onboarding - `username-auditor`, `username+auditor@gitlab.com` 3. [x] Your Admin account (requires manager approval) that was set up during this module or during GitLab.com SaaS Basics - `username-admin`, `username+admin@gitlab.com` ## Stage 3: Important SaaS Definitions/Things to Know ### Support Entitlement - [x] Reviewed As per our [statement of support](https://about.gitlab.com/support/statement-of-support/#free-users), technical and general support for those using the Free version of GitLab.com is “Community First”. Like many other free SaaS products, users are first directed to find support through community sources such as the following: - [GitLab Documentation](https://docs.gitlab.com/): Extensive documentation on anything and everything GitLab. - [GitLab Community Forum](https://forum.gitlab.com/): Get help directly from the community. When able, GitLab employees also participate and assist in answering questions. - [Stack Overflow](https://stackoverflow.com/): Please search for similar issues before posting your own, as there's a good chance someone else had the same issue as you and has already found a solution. **Note:** GitLab Support can assist free users with the following types of issues: - Your account or repository is in an unusable state. For example, you're unable to log in to your account or access a repository without receiving an error that you cannot bypass. Please note though that Account Recovery and 2FA Resets support is not available for Free users. - Requests related to an email you received regarding a GitLab.com security or production incident. ### User Action First - [x] Reviewed GitLab Support has a clear preference for [user action first](https://handbook.gitlab.com/handbook/support/workflows/account_changes/#user-action-first). Actions should only be taken on [behalf of a user](https://handbook.gitlab.com/handbook/support/workflows/account_changes) when all self-service options have been exhausted. ### Enterprise Users [Enterprise users](https://docs.gitlab.com/user/enterprise_user/) are users accounts on GitLab.com that are **owned and administered** by an organisation. Enterprise users are [typically treated differently](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#account-verification-matrix) than non-enterprise paid users for account related support. #### Enterprise User Criteria - [x] Reviewed User accounts on GitLab.com are claimed as Enterprise Users whenever the meet the following [criteria](https://docs.gitlab.com/user/enterprise_user/#automatic-claims-of-enterprise-users): 1. The user's primary email has a domain that has been [verified](https://docs.gitlab.com/user/enterprise_user/#verified-domains-for-groups) by the paid group. 2. The user account meets at least **one** of the following conditions: - It was created February 1, 2021 or later. - It has a SAML or SCIM identity tied to the organization's group. - It has a `provisioned_by_group_id` value that is the same as the organization's group's ID. - It is a member of the organization's group, where the subscription was purchased or renewed February 1, 2021 or later. Enterprise users will have an `Enterprise` badge beside their name when managing a group/project's members. For the purposes of support, a user can still be considered if they meet the [support definition criteria](https://handbook.gitlab.com/handbook/support/workflows/gitlab-com_overview/#enterprise-users). **Note the difference** here with a domain being "Verified" and "Owned" ### Account Ownership Verification - [ ] Reviewed For many tickets on GitLab.com, Support Engineers need to complete [account ownership verification](https://handbook.gitlab.com/handbook/support/workflows/account_verification/) with the customer before certain tasks can be done. As a guide, account ownership verification should take place for any tickets requesting changes to be made to an account. However, there may be certain scenarios where ownership verification needs to take place before certain information can be disclosed in a ticket. - [ ] Review the [account ownership verification matrix](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#account-verification-matrix) to understand eligibility for account ownership verification. - [ ] Review the [standard account ownership verification questions](https://gitlab.com/gitlab-com/support/zendesk-global/macros/-/blob/master/active/Support/SaaS/GitLab.com/Account%20Ownership%20Verification%20-%20GitLab.com.md?ref_type=heads). - [ ] Review the [checking challenge answers section](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#step-2-checking-challenge-answers) in the support workflow. - [ ] Review what to do [when a user proves account ownership](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#step-3a-user-successfully-proves-account-ownership). - [ ] Review what to do when a [user **fails** to prove account ownership](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#step-3b-user-fails-to-prove-account-ownership). - [ ] Review [how to authenticate an owner vouch](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#authenticating-an-owner-vouch). - [ ] Review an [example owner vouch](https://gitlab.com/-/snippets/4816043) [snippet](https://docs.gitlab.com/user/snippets/). #### Important note on account ownership verification answers Account ownership verification answers must relate to the user who sent the answers on the ticket. We cannot accept answers on behalf of another user (except for cases [when owners can answer questions](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#account-verification-matrix)). If this happens, ask the customer to add the relevant user to the [CC'd emails](https://about.gitlab.com/support/portal/#adding-additional-participants-ccs-to-your-ticket) on this ticket and provide the answers from that address. ### Namespaces - [ ] Reviewed A GitLab [Namespace](https://docs.gitlab.com/user/namespace/) organises subgroups and projects in GitLab. This simply refers to the **top-level** group, for example [gitlab-org](https://gitlab.com/gitlab-org) is a namespace. Be aware of the [different types of namespaces](https://docs.gitlab.com/user/namespace/#types-of-namespaces) and their characteristics. ### Admins No customers have access to the [admin area](https://docs.gitlab.com/administration/admin_area/) on GitLab.com. Only select team members have access. Review the following user administration tasks on GitLab.com: - [ ] [Deleting a user](https://docs.gitlab.com/administration/admin_area/#delete-a-user) - [ ] [Impersonating a user](https://docs.gitlab.com/administration/admin_area/#user-impersonation) - [ ] Be aware of the [consequences of impersonating users](https://handbook.gitlab.com/handbook/support/workflows/account_changes/#impersonating) - [ ] **Note:** GitLab Support are required to [ask for explicit permission](https://handbook.gitlab.com/handbook/support/workflows/account_changes/#asking-permission) to impersonate users. - [ ] Impersonation of users should only be done as a last resort. Remember [user action first](https://handbook.gitlab.com/handbook/support/workflows/account_changes/#user-action-first). - [ ] [Viewing user identities](https://docs.gitlab.com/administration/admin_area/#user-identities) - useful for [SAML](https://docs.gitlab.com/user/group/saml_sso/)/[SCIM](https://docs.gitlab.com/user/group/saml_sso/scim_setup/) or [sign-in service](https://docs.gitlab.com/user/profile/#sign-in-services) related issues - [ ] [Add email to user](https://docs.gitlab.com/administration/admin_area/#add-email-to-user) useful for [Enterprise User primary email changes](https://handbook.gitlab.com/handbook/support/workflows/account_changes/#change-primary-email-address-of-enterprise-users) - [ ] [Admin notes](https://handbook.gitlab.com/handbook/support/workflows/admin_note/) ### User States User accounts can be in multiple states on GitLab.com. Review our documentation and understand the various states: - [ ] [Blocked accounts](https://docs.gitlab.com/administration/moderate_users/#block-and-unblock-users) - [ ] [Banned accounts](https://docs.gitlab.com/administration/moderate_users/#ban-and-unban-users) - [ ] [Locked accounts](https://docs.gitlab.com/security/unlock_user/) ### Using Kibana All GitLab.com logs can be viewed in Kibana. The log retention period for GitLab.com is 30 days. Kibana logs can be useful for SaaS and SaaS Account related tickets, so it is good to have understanding of how to use it. - [ ] Review [Using Kibana](https://handbook.gitlab.com/handbook/support/workflows/kibana/) Here are some sections that are useful for SaaS Account tickets: - [ ] Review [Deleted User](https://handbook.gitlab.com/handbook/support/workflows/kibana/#deleted-user) - [ ] Review [Disabled Two Factor Authentication](https://handbook.gitlab.com/handbook/support/workflows/kibana/#disable-two-factor-authentication) - [ ] Review [Enable/Disable SSO Enforcement](https://handbook.gitlab.com/handbook/support/workflows/kibana/#enabledisable-sso-enforcement) - [ ] Review [Searching for remove user from group](https://handbook.gitlab.com/handbook/support/workflows/kibana/#searching-for-remove-user-from-group-or-subgroup) > [!note] > > Be aware of the [Log and audit requests](https://handbook.gitlab.com/handbook/support/workflows/log_requests/) support workflow to understand when/how we can share logs with customers. ### Audit Events Some audit events appear in the GitLab UI. This can be accessed by users also, but their scope is limited to their group. GitLab.com admins are able to view audit events for the whole instance, the same way a self-managed admin could do. - [ ] Review the [audit events documentation](https://docs.gitlab.com/user/compliance/audit_events/) and be aware of its capabilities **Note:** Some logs/events can be easily found in audit events. The benefit of this is, if an audit event exists on a group level, this link can be shared with a customer (provided they are a named support contact and group owner) ### Triaging Many common tickets are triaged to other places. 1. [ ] Personal Data Access and Account Deletion requests: review the [workflow](https://handbook.gitlab.com/handbook/support/workflows/account_deletion_access_request_workflows/) and the [introduction page](https://handbook.gitlab.com/handbook/support/workflows/personal_data_access_account_deletion/) to understand how to process these types of requests. Note that there are macros in Zendesk for these cases. 2. [ ] Subpoenas and other legal (court) requests. See [Subpoenas and other requests for information](https://handbook.gitlab.com/handbook/support/workflows/information-request/) - Note: If the customer request is _not_ tied to an active court case or other legal matter, it may fall under one of the other cases below. 3. [ ] Read over the [example cases that we redirect to Security](https://handbook.gitlab.com/handbook/support/workflows/working_with_security/). 1. [ ] [Copyright (DMCA) Removal Requests](https://handbook.gitlab.com/handbook/support/workflows/dmca/#submitting-a-dmca-request) has its own email. ## Stage 4: Common SaaS Account Requests 1. [ ] Review the `GitLab.com -> Accounts` [Support Workflows](https://handbook.gitlab.com/handbook/support/workflows/) to make yourself aware of some of the documented workflows we have in place. - [ ] \[Optional\] You may want to bookmark the following workflows, as they do appear quite often: - [Account Ownership Verification](https://handbook.gitlab.com/handbook/support/workflows/account_verification/) - [2FA Removal](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/) - [Lost Email Account](https://handbook.gitlab.com/handbook/support/workflows/lost_emails/) 2. [ ] Be aware (optionally bookmark) the [Internal Support Workflows](https://internal.gitlab.com/handbook/support/workflows/) page (internal link) ### Identity Verification Users on GitLab.com are subject to [Identity Verification](https://docs.gitlab.com/security/identity_verification/) before they can start to use the platform. The degree of information users are required to provide for Identity Verification varies based on their [Arkose Risk Score](https://docs.gitlab.com/integration/arkose/). At the time of writing, it is as follows: - **All users**: Email verification - **Medium-risk users**: Phone number verification - **High-risk users**: Credit/Debit card verification 1. [ ] Make yourself aware of the [unsupported](https://docs.gitlab.com/security/identity_verification/#unsupported-countries) and [partially supported](https://docs.gitlab.com/security/identity_verification/#partially-supported-countries) countries for phone SMS verification. 2. [ ] Make yourself aware of the [internal support workflow](https://internal.gitlab.com/handbook/support/workflows/phone-number-verification/) for Identity Verification exemptions. - [ ] Pay attention to [Phone verification logs and examples](https://internal.gitlab.com/handbook/support/workflows/phone-number-verification/#phone-verification-logs-and-examples) to be aware of how Support can view logs for identity verification attempts. 3. [ ] Make yourself aware of the Identity Verification Exemption requests [internal handbook page](https://internal.gitlab.com/handbook/security/security_operations/trust_and_safety/guides-and-documentation/identity-verification-exemptions-requests/). - [ ] Pay close attention to [Requesting an exemption](https://internal.gitlab.com/handbook/security/security_operations/trust_and_safety/guides-and-documentation/identity-verification-exemptions-requests/#requesting-an-exemption) including [Cases where Support team members can create exemptions](https://internal.gitlab.com/handbook/security/security_operations/trust_and_safety/guides-and-documentation/identity-verification-exemptions-requests/#cases-where-support-team-members-can-create-exemptions-themselves) ### 2FA Removal Users can enable [two-factor authentication (2FA)](https://docs.gitlab.com/user/profile/account/two_factor_authentication/) to provide an additional layer of security to their GitLab account. Users with 2FA enabled, can lose their authenticator/device and submit a request to GitLab Support to reset their 2FA. **As of 2020-08-15, GitLab Support no longer processes 2FA removal requests for free accounts.** In the case of any customer requesting 2FA removal, they will first be pointed to GitLab's available self-service options: 1. [Use saved Recovery Codes](https://docs.gitlab.com/user/profile/account/two_factor_authentication/#recovery-codes) 2. [Generate new Recovery Codes](https://docs.gitlab.com/user/profile/account/two_factor_authentication_troubleshooting/#regenerate-recovery-codes-with-ssh) using previously added SSH keys **Note**: the above self-serve options are also available to free users #### Important things to note - [ ] Ensure you always [keep the ticket simple and accurate](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#keep-the-ticket-simple-and-accurate) for 2FA removal tickets - [ ] Review [the conditions for SaaS users to be eligible for a 2FA reset](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#conditions-for-gitlabcom-users). - [ ] If you haven't already, review the [account ownership verification](#account-ownership-verification) section of this training module. The same verification is used for 2FA removal tickets for requests not initiated by an enterprise owner. - [ ] Review the different process for account ownership verification for [2FA removal requests initiated by enterprise owners](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#request-for-2fa-removal-initiated-by-an-enterprise-owner). - [ ] All 2FA removal tickets **require a peer-review** when a user can prove they own the account in question. You can request this in `#support_gitlab-com` slack channel. #### Workflow ##### [Request for 2FA removal initiated by the account holder](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#request-for-2fa-removal-initiated-by-the-account-holder) 1. [ ] Zendesk performs [validation](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#step-0-validation) steps on the customer and the ticket 2. [ ] Customer will be sent the **standard** [account ownership verification questions](https://gitlab.com/gitlab-com/support/zendesk-global/macros/-/blob/master/active/Support/SaaS/GitLab.com/Account%20Ownership%20Verification%20-%20GitLab.com.md?ref_type=heads) 3. [ ] Customer will respond with their answers to the questions. - **Note**: be aware that answers must be in relation to the user who submitted them on the ticket. Re-review this [section](#important-note-on-account-ownership-verification-answers) if necessary 4. [ ] Agent will review whether the customer is [eligible](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#conditions-for-saas-users) for 2FA reset. 5. [ ] Agent will review the [account ownership verification matrix](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#account-verification-matrix) to verify from whom we can accept the challenge answers. 6. [ ] Agent will [assess the customer's challenge answers](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#step-1-checking-challenge-answers). - If customer passes, follow the steps [here](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#step-2a-user-successfully-proves-account-ownership). - If customer fails, follow the steps [here](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#step-2b-user-fails-to-prove-account-ownership). > [!note] > > For requests initiated by the account holder/a non-enterprise owner, the questions can be assessed using this [internal handbook page](https://internal.gitlab.com/handbook/support/#risk-factors-for-an-individual-trying-to-access-their-own-account) manually. These requests can no longer be verified with the Zendesk GitLab Super App. **Note:** for requests created by the account holder, as per the [account ownership verification matrix](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#account-verification-matrix), if an owner is required, a new ticket must be created. ##### [Request for 2FA removal initiated by an enterprise owner](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#request-for-2fa-removal-initiated-by-an-enterprise-owner) 1. [ ] Zendesk performs [validation](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#step-0-validation-1) steps on the customer and the ticket 2. [ ] Customer will be sent the enterprise owner verification questions and be requested to provide their [support pin](https://docs.gitlab.com/user/profile/#generate-or-change-your-support-pin). 3. [ ] Customer will respond with their support pin. 4. [ ] Agent will review whether the customer is [eligible](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#conditions-for-saas-users) for 2FA reset. 5. [ ] Agent will review the [account ownership verification matrix](https://handbook.gitlab.com/handbook/support/workflows/account_verification/#account-verification-matrix) to verify from whom we can accept the challenge answers. 6. [ ] Agent will [assess the customer's support pin](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#step-1-checking-challenge-answers) and calculate the appropriate risk factor using the 2FA Helper in the GitLab Super App. - [ ] If customer passes, follow the steps [here](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#step-2a-enterprise-owner-successfully-proves-their-identity). - [ ] If customer fails, follow the steps [here](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#step-2b-enterprise-owner-fails-to-prove-their-identity). **Note**: be aware of the [backup methods available for authenticating an owner](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#backup-methods-for-authenticating-an-owner) #### 2FA Removal Review Process All 2FA Removal tickets are required to be reviewed by more than one support engineer. This helps to ensure all requests and assessments are valid whilst reducing the risk of any mistakes being made. ##### Requesting peer review If you are the assignee of a ticket, you would follow the relevant [workflows](#Workflow) as normal. However, if the user **passes verification**, then we need to request a peer support engineer to review the assessment. This is typically requested via a message in `#support_gitlab-com` slack channel with a message similar to below: > Hi team :wave: - 2FA review for \<link_to_ticket\> Another support engineer will complete review of your ticket. If their assessment also passes, then the **reviewing engineer will proceed to disable 2FA for the user**. ##### Completing a peer review Anyone can complete a peer review of a 2FA ticket for another engineer. Keep an eye on `#support_gitlab-com` slack channel for other support engineers requesting a peer review. Follow the below process when completing a peer review: 1. React with :eyes: on the message to indicate to the support engineer that you are reviewing their ticket. 2. Follow the relevant [workflow](#workflow) as if you were working on the ticket. 3. **If they pass**, follow [these steps](https://handbook.gitlab.com/handbook/support/workflows/2fa-removal/#step-2a-user-successfully-proves-account-ownership) 4. React with :white_check_mark: on the initial message and remove the :eyes: reaction to indicate the review was completed. 5. **If they fail**, react with :x: on the initial message and remove the :eyes: reaction to indicate the review failed. On the Slack thread, provide the rationale for the user failing the review. ### Lost Email Address There are certain scenarios where customers lose access to all emails associated with their account. Accounts that meet [certain conditions](https://docs.gitlab.com/security/email_verification/#accounts-without-two-factor-authentication-2fa) may be required to receive a verification code to their email address when signing in to GitLab.com. If a customer has lost access to their email address, they can request that the security email be sent to any verified secondary email address on the account (if applicable). The [support workflow](https://handbook.gitlab.com/handbook/support/workflows/lost_emails/#stage-1-process) for lost email accounts clearly outlines the action GitLab Support can take in the scenarios. - [ ] Review the lost email [support workflow](https://handbook.gitlab.com/handbook/support/workflows/lost_emails/#stage-1-process) and be aware of the actions we can take for paid and free customers. ### Account Reinstatements (Blocked, Locked and Banned Accounts) There are many circumstances where users can be blocked, locked or banned. There are several ways to check an account's status: - The best way to view this information is via the Zendesk User Lookup app (part of the GitLab Super App), through the Locked and State fields. - The Admin User UI in `/admin/user/USERNAME` will say (Locked), (Blocked) or (Banned) next to the name at the top. - The Users API through the URL `https://gitlab.com/api/v4/users/<user_id>` in your browser while logged in as an Admin User, also indicates the locked and state status of the user. The actions we can take on users who are blocked, locked or banned are contained within our [support workflow](https://handbook.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts). Review the following sections: - [ ] [Locked accounts](https://handbook.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts/#locked-accounts) - [ ] [Blocked accounts](https://handbook.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts/#blocked-accounts) - [ ] [Banned accounts](https://handbook.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts/#banned-accounts) #### Account blocked after deletion When a user initiates a [self-service deletion](https://docs.gitlab.com/user/profile/account/delete_account/#delete-your-own-account), their account is soft deleted for 7 days. During this time, the [account becomes blocked](https://handbook.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts/#user-initiated-self-serve-deletion). In these cases, GitLab Support can unblock the account. Review our [workflow](https://handbook.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts/#cancelling-delayed-account-deletion) to understand when we can action such requests. ### Namesquatting According to our [statement of support](https://about.gitlab.com/support/statement-of-support), namespaces may be released when they meet the appropriate criteria, and requested by a paid customer (member of a paid namespace or a self-managed customer migrating to SaaS). Review the below regarding namesquatting requests: - [ ] [Namesquatting Support Workflow](https://handbook.gitlab.com/handbook/support/workflows/namesquatting_policy/#workflow) - [ ] [Namesquatting FAQs](https://handbook.gitlab.com/handbook/support/workflows/namesquatting_policy/#faqs) ### Unable to log in after password reset Sometimes, customers can raise requests stating that they are unable to log in with their email address and password after resetting their password. This is because secondary email addresses can be used to reset passwords and to receive verification codes, however it cannot be used for authentication (i.e. logging in), as per our [documentation](https://docs.gitlab.com/user/profile/#add-emails-to-your-user-profile). This can be quite common, in these cases we can use the `Primary Email Required For Password Resets` macro. > [!warning] > > GitLab Support cannot disclose email addresses associated with accounts, however with this macro, we can inform them that the address they provided is not the primary address of any GitLab.com account. ### Enterprise user not able to sign in Sometimes enterprise users may report that they are unable to sign in to GitLab.com nor request a password reset email. This is usually due to the namespace having [disabled password authentication for enterprise users](https://docs.gitlab.com/user/group/saml_sso/#disable-password-authentication-for-enterprise-users). To investigate this, you can do the following steps: 1. Log in to GitLab.com on your admin account 2. Visit the group in question (non-admin view) - `gitlab.com/<namespace_name>/-/saml` 3. Check for `Disable password authentication for enterprise users` being enabled If this is enabled, we can advise the customer that this setting is preventing this and advise the user to sign in with their SAML SSO credentials. We can verify if a user has a SAML SSO identity, by navigating to `gitlab.com/admin/users/<username>/identities`. Look out for `Group Saml (group_saml)` and ensure that the `Group` value matches the group in question. ### Not receiving emails Customers may create tickets time-to-time stating that they are unable to receive emails from GitLab.com. This can be for a multitude of reasons, including their address being suppressed by Mailgun, notification settings being disabled, typo in email address and mail server issues at the customer's side. - [ ] Review [Checking Mailgun logs](https://handbook.gitlab.com/handbook/support/workflows/confirmation_emails/#checking-mailgun-logs) - [ ] Review [Manually removing a suppression in Zendesk](https://handbook.gitlab.com/handbook/support/workflows/confirmation_emails/#manually-remove-a-suppression-in-zendesk) - [ ] Review [Manually removing a suppression in Mailgun](https://handbook.gitlab.com/handbook/support/workflows/confirmation_emails/#manually-remove-a-suppression-in-mailgun) - [ ] Review [Resend confirmation email](https://handbook.gitlab.com/handbook/support/workflows/confirmation_emails/#stage-3-resend-confirmation-email) - [ ] Review [How to see or resend emails in Mailgun](https://handbook.gitlab.com/handbook/support/workflows/confirmation_emails/#how-to-see-or-resend-emails-in-mailgun) - [ ] Review [Password reset on behalf of a user](https://handbook.gitlab.com/handbook/support/workflows/confirmation_emails/#password-reset-on-behalf-of-a-user) If you have checked the logs and can see the emails being delivered successfully, but the customer is not receiving them, ask them to check with their spam/other folders or alternatively their mail provider/admin. If you see an error message on Mailgun and the email is showing as not delivered, it can help to Google search the SMTP error message received from the customer's mail server. **Note:** Be aware of our [statement of support](https://about.gitlab.com/support/statement-of-support/) and the support that [free users](https://about.gitlab.com/support/statement-of-support/#free-users) are entitled to. Whilst this is not explicitly included in free support, it can be nice to share a simple diagnosis with customers to help them understand the issue, whilst delivering [results for customers](https://handbook.gitlab.com/handbook/values/#results). #### Not receiving password reset emails There are some cases where customers will not receive password reset emails. This could be due to typical issues with receiving emails (such as a suppression), but it could also be due to some other reasons: - If a user account is locked, blocked or banned, they will not receive any password reset emails (no logs in Mailgun either) - [ ] Review [Locked, Blocked and Banned Accounts](https://handbook.gitlab.com/handbook/support/workflows/reinstating-blocked-accounts/) - If a user is an [enterprise user](https://docs.gitlab.com/user/enterprise_user/) and the namespace has [disabled password authentication for enterprise users](#enterprise-user-not-able-to-sign-in) they will not receive a password reset email. ### Personally Identifiable Information (PII) Removal Requests 1. [ ] [Personal Identifiable Information Removal Requests](https://handbook.gitlab.com/handbook/support/workflows/pii_removal_requests/) are not frequently common, but read the workflow to understand Support's responsibility. ### Miscellaneous Requests Of course, there will be scenarios where customers will ask account-related questions that are outside of the documented support workflows. If you are ever unsure, ask in the [#support_gitlab-com Slack channel](https://gitlab.enterprise.slack.com/archives/C4XFU81LG) (internal link). ## Stage 5: Work on Tickets! This module aims to prepare you to be able to take SaaS Account tickets. At this stage, you should be equipped to handle SaaS Account tickets. Pick up and work on at least 2 SaaS Account/2FA Removal tickets and link them below! - [ ] Ticket 1: _link here_ - [ ] Ticket 2: _link here_ `@` your onboarding buddy or manager to review the tickets you have worked on so far! ## Stage 6: Contribute An effort has been made to include as many common SaaS Account related topics as possible. If you encounter any common issues, feel free to contribute to this training issue template! 1. [ ] Manager: schedule a call (or integrate into 1:1) to review how the module went once you have reviewed this issue. 2. [ ] Please submit MRs for this Issue Template with any improvements that you have noticed. 3. [ ] Submit an MR to update your `focuses` slug in your [Support Team yaml file](https://gitlab.com/gitlab-support-readiness/support-team/-/wikis/Support-team-entry) with this training module's topic and the percentage of your time you are dedicated to this Area of Focus. The settings will display on the [Areas of Focus page](https://gitlab-com.gitlab.io/support/team-pages/area-of-focus.html). **NOTE:** if you completed all sections of this module, you should be working on SaaS Account tickets and admin-related internal requests, and your Area of Focus should be "SaaS 50%" or higher. 4. [ ] Update your [Support Team yaml file](https://gitlab.com/gitlab-support-readiness/support-team/-/wikis/Support-team-entry) to indicate that you're learning and working on tickets in this product category: ```yml product_categories: - name: GitLab.com (SaaS) level: 1 ```