This workflow focuses on the process when action is required by the Support team on behalf of the user.
The main situations where action may need to be taken on behalf of the user:
Following our Security Policy on "GitLab's Access to Your Private Repositories", actions should always be taken by the user whenever possible.
For example, users should be deleting their own projects, but if they encounter an error with every attempt and there are no workarounds, then Support can intervene with permission.
If in doubt, please ask a Support manager to review.
In cases where Support needs to take action on the project or group, such as for troubleshooting purposes, Support should do two things:
You can continue working with the original requester once an owner/maintainer provides permission if that is their preference.
In cases where a user has lost access to their account, all other options (such as SSH recovery codes, password reset) should be exhausted first.
For unconfirmed accounts, the only account action support will typically take is an email typo fix.
Before taking any action on confirmed accounts, ensure that you have verified the account owner using the Account Ownership Verification workflow.
If ownership is verified, then:
Example cases include:
Similar to Account Access Requests, if a user has lost access to their account and the account shows no activity in its history, then we can consider releasing the email address for the user to create a new account with.
We can also use this workflow when a user cannot add an email address to their account because it is on a different account and is unverified. This often happens if a user has accidentally created an account using one of the single sign-on registration methods or cannot recall creating the account.
For more information on unverified/unconfirmed accounts, please see the confirmation emails workflow.
The primary (for paid users only, all users should be able to get a new confirmation email) and secondary email (for all users until #367823 is resolved) can be released following the process below.
To release an email address for an inactive account:
Check the user's activity page:
+release. For example, if the email address is
firstname.lastname@example.org, then update the email address on the account to
The Support team will not view any private information unless required to resolve an issue. Typically, the issue is filed by the account holder (for users) or valid members of the namespace (for projects and groups) via a support ticket for troubleshooting purposes as outlined in Security Policy on "GitLab's Access to Your Private Repositories".
A Support team member may look at information on pages not explicitly mentioned in the request, but will limit the scope of the review to the minimum access required to solve any issues.
The Support team will only take action from the requester if they:
We expect users to provide specific links in order to focus on the related views and logs while investigating an issue. For example, a request to look into a CI/CD error should include links to the relevant job logs, pipelines, and/or CI YAML file.
Any time user data needs to be downloaded (such as cloning a repository), or where secrets must be revealed (such as CI/CD Variables), to further troubleshoot, requires explicit permission before continuing. Any user data that has been downloaded for reproduction purposes must be deleted when the issue is resolved.
Before any actions are taken, please request explicit permission to take the required action. Be as specific as possible so that there is no confusion.
Once permission is confirmed by the user, then you may proceed.
Some sample phrases:
Could you please provide permission for Support to … ?
Could you please confirm that you would like us to … ?
Could you please provide permission for Support to re-run one or more pipelines in project
xyzto investigate the issue you've described? Replying in this ticket stating you provide permission will be sufficient.
Could you please provide permission for our Support Engineers to look at the CI/CD variables in the project so that we confirm they are correct? Replying in this ticket stating you provide permission will be sufficient.
Could you please confirm that you would like us to exchange your primary address
email@example.com secondary address
firstname.lastname@example.org your account? Replying in this ticket stating you provide permission will be sufficient.
Impersonating a user is considered performing an action as another account, impersonating will update the Current sign-in IP and Current sign-in at for the impersonated user.
When impersonating a user, the administrator account will receive a slack message from the SIRTbot app asking to confirm if the impersonation was a legit action.
The action of impersonation is in accordance with our Confidentiality Terms of the Subscription Agreement.