1. You are here:
2. Handbook
3. Support Team Handbook
4. Support Workflows
5. Reinstating blocked accounts

On this page

• Overview
  • Process
  • NOTE
    • An account can be reinstated when
    • An account cannot be reinstated when

Overview

This workflow is to determine if a blocked user can be re-instated if it has been blocked by us.

All blocked accounts should have an admin note with a link to a relevant issue.

Process

1. Only proceed with the next steps if any of the following scenarios is true:
   1. The email address the user has used to raise their request matches an email address associated with the account the request is intended for.
   2. The user account is classified as an Enterprise user and an owner of the top-level group raises the ticket.
2. If the account is blocked, look for the admin note on the account to determine why it has been blocked.
   • The (GitLab user lookup app in Zendesk will show the admin notes for the user if they have contacted support using the email address associated with their account. Alternatively -
   • If you have access to ChatOps you can use the below command in any chatops enabled Slack channel to read admin notes for the user

     /chatops run user find <username or email>

3. If the block or complaint is related to access from an embargoed country, use the Support::SaaS::Abuse::TOS Section 10 (Embargoed Countries) macro.
   • If the user provides the requested information, then complete the Trust and Safety Account Reinstatement Request template in the Trust and Safety Operations tracker. Otherwise, reaffirm the block cannot be removed.
4. Professional Services migrations can also block users as part of their process. Admin notes for migrations were added as of 2022-08-19 through this issue. Older migrated accounts may not have an admin note. You can ask in the #professional_services channel if needed.
5. For all other cases, including no admin notes that are not a part of PS migrations, complete the Account Reinstatement Request template in the Trust and Safety Operations tracker. A security member of the team will review the request within 24 hours. If the request is urgent, please reach out in the #abuse Slack channel.
6. Send the Support::SaaS::Blocked Accounts::Escalated-TrustAndSafety macro for the initial response to the user.
7. If established it is not a Trust and Safety block, or is blocked as a result of a SM-to-SaaS migration (conducted with or without Professional Services), a paid account can be unblocked with authorization from a user with the Owner role in the top level namespace. Free accounts can be unblocked at the discretion of the Support Engineer.
8. If account is unblocked, use the Support::SaaS::Blocked Accounts::Account Reinstated- Success macro to notify the user the account has been unblocked. Otherwise, provide the reasoning from the Unblock Request as to why their account will remain blocked.

Note: The rest of this page is for reference only and should be updated to point to Security's workflow.

NOTE

1. All decisions about account reinstation are final and there is no process for appeals.
2. These criteria are to be taken as examples only, and not as binding principles.
3. If the account violates our ToS again within a 12 month period, it could result in being permanently banned.

An account can be reinstated when

1. The user agrees to remove the content in question within the requested timeframe.
2. The user has provided a sufficient use case for violating our Terms of Use.
3. The user agrees to remove or export the content away from GitLab.com within 24 hours.
4. The DMCA/Trademark complaint has been resolved.

An account cannot be reinstated when

1. The user refuses to take corrective measures on the account.
2. The user continues to violate our ToS.
3. The user intentionally violates our ToS.
4. Any abusive language or hostile activity towards the support engineer.
5. The account presents damage to the GitLab business and/or brand.