This is the request an account guide
Shortcuts WP:ACCG WP:ACC/G This page is the standard operating procedure manual for ACC tool users and ACC tool administrators. If you're looking to request a new account, click here to be redirected to the correct page. Access the interface

The Account Creation Interface is an application software hosted on Wikimedia Cloud VPS that is used to facilitate account creation requests on the English Wikipedia. This guide describes accepted practices in handling requests that are submitted to the tool. Users who wish to participate in this process must apply for access pursuant to the required qualifications that are listed in this guide. New interface users should read this page thoroughly and experienced users should periodically check for updates.

After meeting the qualifications below, you must register here before handling requests using the interface. Your request must be approved by a tool administrator and if approved, you will receive a notice on your talk page. In the event that your request is denied, you will receive an email explaining why. After you have addressed all the concerns in the email, you can reapply for access to ACC by sending an appeal email to the tool administrators. Your appeal should address all the concerns raised in the email explaining the reasons for your denial from ACC. Please do not create more than one ACC account for yourself.

• Interface administrators (herein referred to as tool administrators or administrators) are not the same as Wikipedia administrators (herein referred to as sysops). Most Wikipedia sysops are not tool administrators.
• Tool accounts that have not been logged into for 90 days will likely be suspended due to inactivity (this is for security purposes). If your account becomes suspended due to inactivity, simply contact a tool admin in order to regain access again.
• Despite the similar names, you do not need the "account creator" right to use the account creation interface. This is an entirely separate permission from being granted access to the interface itself. Your rights as a regular Wikipedia editor are sufficient to create accounts in normal situations. After gaining experience using the account creation interface, you may wish to apply for the "account creator" right which lets you handle more complex cases and override certain limits.

To qualify as an ACC user, you must meet the following minimum requirements:

• You must sign the confidentiality agreement for access to nonpublic information per Wikimedia Foundation policy. Please ensure that you are listed on the access to nonpublic personal data policy noticeboard before requesting access to ACC. Submitting a request to join ACC before you are listed on the access to nonpublic personal data policy noticeboard will likely result in an administrator rejecting your request, requiring you to submit an appeal by email once you have been listed.
• You have a clean block log or if you have had a block it must not be recently placed (preferably not within 6+ months, depending on length of block.)^{[note 1]}
• You need a valid email address that you actively watch that must be subscribed to the mailing list. (Signup here after being granted access to the interface.) Tool policy change notices are sent out this way, and you are responsible for keeping up with them.^{[note 2]}
• You have no recent editing restrictions, had disciplinary action enacted upon yourself (i.e. Arbitration Committee sanctions and editing restrictions) or a history of abuse.
• You must have read, understood and agreed with the ACC guidelines.
• Your account on Wikipedia must be at least 6 months old and have at least 1500 edits.^{[note 3]}
• You have a solid grasp of Wikipedia's policies and guidelines, Wikimedia Foundation's privacy policy and show yourself to be a knowledgeable user.
• You need to be able to accept/acknowledge constructive criticism.
• You are allowed only one account in the tool and should not apply for more than one.
• You need to wait a reasonable amount of time before appealing an account decline or suspension decision. Also, excessive appeal requests without taking enough time to properly consider and address the original deny reason will not be considered.
• You must connect your account to your Wikipedia account during signup.^{[note 4]}

This list is not exhaustive, but are the primary reasons tool admins consider when looking at a request for an account.

Finally, the acceptance of requests are subject to the opinions of tool administrators based on the demonstrated trustworthiness, competence of the candidate, and the apparent need for more users.

If you previously requested to join ACC but were declined, please submit an appeal by emailing the tool administrators. Please do not create more than one ACC account for yourself.

The tool will prompt you to connect your tool account to your Wikipedia account. This is done using the OAuth protocol, which gives the tool rights to perform certain actions on Wikipedia on your behalf. This is primarily used to gain a cryptographically signed identity ticket from Wikipedia verifying that you have control of an account on Wikipedia. All tool users are required to connect their tool account to Wikipedia, but the additional permissions are optional.

You can see the information the tool stores about your on-wiki identity from your tool preferences.

After logging in, you will see the main interface (see screenshot) — which displays a list of:

• Open requests
• Flagged user needed – requests needing account creator rights.
• Checkuser needed – requests needing CheckUser attention.
• On hold – generally requests where we are waiting on feedback from someone, typically the requester, but sometimes from a tool admin or sysop.
• Proxy check needed – requests needing to be checked by those with proxy experience.
• Last 5 closed requests – list of last five closed requests with zoom and reset buttons.

Request categories which need to be worked will show a number next to their title, such as Open requests 2. To view the two requests, click on Open requests. To work on a specific request, click on the green Reserve button. You will be marked as handling the request and be provided with personally identifying information of the requester and the ability to create/decline/drop the request as appropriate following the guide below.

Please remember that account creating is not a race! The requests that end up in the ACC interface are accounts which couldn't have been created under normal circumstances. Please keep this in mind and react thoughtfully. It happens sometimes that one is in the middle of a situation and one doesn't know what action to take. Just ask in the ACC IRC Channel for help in situations such as these: #wikipedia-en-accounts ^connect.^{[note 5]} There are always other interface users online who are willing to assist you. In case you do not get a satisfactory response, and do not know which course to undertake, it is better to defer the request to other users rather than to undertake a wrong course of action. If you ask for help, you will need to provide (to non-admin users) the link shown on the 'zoom' page to the other user to allow them to see the private data.

Please note: If you seem to rush through a request (for example, by not performing all the checks listed below), you may lose access to the tool. It is essential that all the checks are performed to ensure that accounts are correctly created or declined.

Buttons on the interface and what they do

Top links In the header of every page, there are a number of links: Requests: returns you to the request queue Meta: Logs: shows recent activity Users: shows all users with access to the tool, categorized by status Search: allows a search of the ACC logs (not Wikipedia's creation logs) Statistics: shows statistics about the ACC tool and the users of the tool Admin: (view only) Ban Management: allows an admin to ban and shows all active bans Close Email Management: which are sent to the requester when the request is closed Welcome Template Management: which are posted to the requester new talk page after it is created Site Notice Management: (admins view only) edit the site notice banner at the top of the page User management: (admins view only) where interface users can be approved, blocked, promoted to admins or demoted to users Job Queue: view the list of pending background jobs, including user creations and welcomes Jump to request ID: Enter a number here to jump to a specific request Your User Name: on the far right side – allows you to change your settings: My Statistics: shows your statistics for tool activity Edit Preferences: such as your email address, email signature, link account to Wikipedia Change password: Change your tool password Configure multi-factor credentials: Configure two-factor authentication Guide: Opens this guide Username Policy: Links to WP:UPOL Similar account flowchart: A basic flowchart showing how to handle similarly named accounts Chat: Join #wikipedia-en-accounts connect IP Address links The IP Address links group contains the following links: Talk Page links to the IP's talk page Local Contributions links to the IP's contributions on the English Wikipedia Deleted Edits link to edit counter showing deleted edits Global Contributions links to the IP's contributions across all Wikimedia projects Local Blocks Log links to the IP's block log on the English Wikipedia Active Local Blocks checks for any applicable current IP blocks on the English Wikipedia Global Blocks links to the IP's global block log on Meta Active Global Blocks checks for any applicable current IP blocks or locally global blocks Rangeblock finder checks for expired and current rangeblocks which apply to the IP Whois runs a WHOIS on the IP (alt) uses whois.domaintools.com instead of the Toolforge tool. Abuse Filter Log shows all actions from the IP that tripped an Edit Filter This section could take three forms, just a plain list of links if the request was made directly to the tool (almost never the case on the Cloud VPS), or it could have come via a proxy or a set of proxies. For more information on how to interpret these, see this page. User name links The User name links group contains the following: User page: A link to the user page of the requested account Creation log: A link to check the creation logs of the requested account SUL: A link to check the existence of the requested user name on other Wikimedia projects Special:CentralAuth: A link to MediaWiki's global user manager Username list: A link to the user list to check for similar account names Wikipedia mainspace search: A link search Wikipedia based on the requested account name Google search: A link to Google, which searches occurrences of the requested account name on Google's search index You should also check the username. Remember to keep username policy in mind when reviewing a name. Always do a Google search to see if it is the name of a company or organization, which may be considered promotional, indicate a conflict of interest and a violation of Username Policy. If the name is ambiguous, then you should take where the requester's IP Address geolocates to in relation to the relevant company, the requester's email address and the requester's comment into consideration. It is also important to check whether the requested username made any contributions on other Wikimedia Projects. This way you could see whether the requested name forms part of a global account or unified login — if so the account should not be created. When you are pleased with the request you can click the Create! link to create the account. Account creation link The Account creation link group contains the following in "manual" mode: Create!: A link to create the requested account – which will open up Wikipedia for you to actually create the account. See further instructions below at Guidelines for Closing Requests. Created! if you were able to create the account. Note the arrow to the side which allows you to choose a more-specific template. In an automatic mode ("Use my Wikimedia account"), these two buttons are replaced with a single button ("Create and close as Created!") which creates the request in the background, and closes the request with the chosen message. If more than one mode is available to you, you will see a set of radio buttons allowing you to choose the mode to use. If you have automatic welcoming enabled, you will see a switch to disable automatic welcoming for this request only. Request Status The Request Status group contains the possible resolutions that can be given to a request: Decline if you are declining to create the account Too Similar if it is too similar — see below for details Taken (Standard) if the username was already taken (but if the username was created a very short while after the request — for example a few minutes after — then you can assume that it is the same user, and Drop the request instead) UPolicy if the requested username violates the username policy Invalid if it contains bad characters—such as # / | [ ] { } < > @ % : , or double spaces between names. Do not use this for usernames with non-Latin characters as these are allowed. Also note that in some cases bugs in the tool may replace certain non-Latin characters in a username with invalid characters when filling in the username field on Special:Userlogin. In such cases it is recommended that you attempt to manually copy and paste the name as it appears in the ACC interface into the username field. Taken (SUL Finalization) if the username is already a part of a SUL account. Password Reset if you have sent a password reset email to a similar username, because it was created recently and appears to belong to the requester. Note that if it was created very recently (e.g. a few minutes after request) you can assume that the requester managed to create it and Drop the request, after commenting an explanation Open Proxy if the requester made the request from a known open proxy Notable Person if the requested username appears to represent a notable person Shared Username if the requested username violated Shared Username provision of Username policy Block target – appeal if the request relates to the user wanting to appeal a block Custom close the request and send a custom email to the user. Defer if you were unable to complete the request and need to defer it to another queue Defer to users often used by CheckUsers or admins to return the request to the normal user queue for further processing and checks Defer to flagged users if a user with the accountcreator permission needs to handle the request Defer to checkusers if the request needs to be checked by a checkuser before continuing Defer to on hold places the request in a separate queue pending further information from the requester or admin Defer to proxy check if the request needs to be checked by a user with proxy experience before continuing Drop if the request is a bad request, or needs to be closed in a way which does not send an email to the requester. You should usually comment to ensure others know why you dropped a request. Sometimes a ban accompanies a drop, see below The SUL Taken option should be used when the requested name is part of a unified login—such as described in the previous section. If the username is similar to that of somebody on another wiki then the Similar option should be used, and if the username is the same as somebody on another wiki then Taken should be used. When none of the above options describes the particular situation, you should use the Custom option. You would then be prompted for a custom email message that would be sent to the requester. The message you write will form the entire content of the email to the user; don't forget to sign your message with an adequate name. Note: All of these links perform an action on the request and do not link to the relevant policy. All resolutions except the Defer and Drop resolutions send an e-mail to the requester indicating what has happened to the request. If the request was already closed or deferred to account creators, then the Defer to account creators link becomes Defer to users, which returns it to the main queue. Ban links The ban links is only available to the tool administrators and contains the following three ban links: One for banning the IP address. One to ban the e-mail address. One to ban the requested account name. Ban links can be found in a separate section beneath "Request status" on the zoom page of a request or in the form of a dropdown button on the main interface beside requests in the request queue. Alternatively, tool admins can ban users and review the active ban list on the ban management page. Access Tool administrators can change other users' access to the interface via User management. Available options—which vary based on the target user's status, are as follows: Count — Checks the edit count of users needing approval. Approve — This allows newly registered users to log in and use the interface. Decline — This declines a request from a newly registered user, preventing them from logging in and using the interface. Rename — Rename a user's interface account. Edit — Edit a user's email address and on-wiki username. Edit roles — Edits the roles granted to a user, such as whether or not they are a tool administrator. Suspend — The equivalent of a block on Wikipedia. It is issued by a tool administrator and prevents the target user from logging in. Unsuspend — The equivalent of unblocking someone. Undoes suspension and allows the user to resume using the interface. Welcome template management Before adding a template, please check that it takes a signature as a parameter, or not at all. This is to prevent the bot signing as itself, rather than the person who created the account. Also, please add the template to the list here, so should the template appear at TfD or a similar venue and gets deleted, (e.g. here), it is actually shown as used. Request reservation To alert other users that a request is already being handled, you must reserve a request to see the full request (unless a tool admin). The tool will not allow you to handle a request which has been reserved by another user and will warn users if they attempt to reserve more than one request. If you need to collaborate with another user on a request, you can use the link titled "reveal to others" to allow other tool users to see the data on the request without needing a reservation. Requests will be automatically unreserved when you close them, however, closed requests can be reserved. All currently reserved requests will show up on one of the statistics pages, accessible by clicking the Statistics link at the top of the page.

The tool supports both manual creation of accounts, and automatic creation of accounts via OAuth.

To support automatic creation of accounts, you must have the "High-volume editing" and the "Create accounts" grants enabled (this is the default). As of March 2021, this is also gated behind a separate tool user role during the process of slowly rolling this functionality out.

You should see a set of radio buttons next to the account creation buttons on the View Request page which allows you to choose a method to create the account - either manually (using the existing process), or automatically. You can choose your default method of account creation in Preferences, under "Account Creation Method". Automatic creation handles the creation of the account as part of closing the request, so for automatic creation all you need to do once you have decided to accept the request is choose a close type.

In the background, the tool will queue up the request to be created and closed - you will see the request move to the "Job queue" status, and a creation job will appear in the "Job Queue" page, accessible from the "View job list" button above the request log. If you need to cancel the creation for whatever reason, resetting the request will cancel the queued jobs. There will be a slight delay between queuing a request for creation and the actual creation taking place - depending on the exact time the request was queued, this will likely be between two and four minutes.

Custom closes also support automatic creation. To use automatic creation with a custom close, choose the "Create account & close request as created" option under "Action to take".

In case of a creation failure (for example if an AntiSpoof hit is detected) the request will be deferred to a "hospital" queue and an announcement will be made by the bot on IRC. If this happens, you can check the jobs to discover why the creation failed, and handle this manually. The most common cause of failure is an antispoof or title blacklist hit - the tool will not attempt to resolve this for you; fallback to manual creation is required.

The tool can now also automatically leave users you create a welcome template. While this functionality existed several years ago via a bot, the usage of the bot was deprecated in preference to the current system which uses your account via OAuth.

To support automatic welcoming, you must have the "High-volume editing" and the "Create, edit, and move pages"^{[note 6]} grants enabled (this is the default). You must also choose a welcome template from the "Welcome Template Management" page - if the template you want to use is not listed, please contact a tool admin to add it for you.

Once you have chosen a template, every user you create via the tool will have their user talk page created with that welcome template. Additionally, a new switch will appear beside the creation button allowing you to skip the welcome for this specific request.

In case of a welcoming failure (for example if the user does not exist or the user talk page already exists), a job failure will be noted in the job queue, and an announcement will be made by the bot on IRC. If this happens, you can check the jobs to discover why the welcoming failed, and handle this manually.

The ACC tool contains personally identifying information and is subject to the privacy policy of the foundation. It cannot be shared outside of the interface.

Personally identifying information includes, but is not limited to:

• IP addresses^{[note 7]}
• Email addresses.
• Real names.

In order to comply with Data retention policy:

• Email communication must be limited to their name and email address, other information including IP address or other personally identifying information is prohibited.
• Within the interface, no identifying information should be shared in the comments of a request.
• Outside of the interface, no identifying information should be shared in any venue. See also § Messages outside of the interface.

Additionally, any action that might produce the following is prohibited:

• Excessive information about a block that could allow the IP to be found in the block logs.
• Information that could create a link between a request or username, and any other element of identifying information.

Users who violate this rule and share any personally identifying information outside the ACC tool interface risk immediate and indefinite suspension, as well as the possibility of their identified status being revoked. See this email for more information.

If you reserve a request and then need to go offline without completing the request, please break the reservation beforehand, so that another user can complete the request, unless you have good reason to require the request to be handled by yourself, in which case you must leave a comment. If you do not do this, the request will remain reserved and cannot be created by other users; a tool admin may forcefully break the reservation if you have left no indication as to why you need to keep the request reserved.

In addition, if you are actively working on a request that you have reserved and it's taking some time to handle (generally, more than an hour), please leave a comment on the request indicating that you are working on it and what the issue delaying handling of the request is. This informs other users and admins that you are busy on the request and that you haven't forgotten about it.

In cases where a user has had a request reserved for a long time and they have left a comment explaining the long reservation time, a reasonable effort should be made to contact them before the request is broken. However, requests reserved without explanation for a long time may be broken by an admin without warning, especially if the user holding the reservation can't be found or reached quickly on IRC.

Using a script or other program to automatically handle requests in any way outside that which the tool provides (includes reserving) is prohibited. If you are found to be using automation of any kind or if evidence strongly supports the probability that you are doing so, you risk account suspension for violation of this rule. Using an automated add-on or script to refresh the tool interface page, however, is allowed. The refresh time must be considerate to the interface's resources and kept to as low of a rate as possible. Please keep the rate to once a minute maximum. The #wikipedia-en-accounts channel on IRC contains a live feed of new requests and changes made to them by tool users. This feed is the preferred method to view and monitor than using the interface and any automatic page refreshing tools.

You should check for multiple requests from an IP address or an email address. To do so, click on the request ID button or click on "Zoom" in the list of last 5 closed requests, or go to the logs and click a request number. At the end of the request line—like you see normally for all open requests, you will see the UTC date and time the request was submitted. Farther down the page you would also see a list of other requests—if any, from that IP address or e-mail address.

If there are multiple open requests (but no closed requests) from the same email address, it's possible the user wanted to change their requested username. Place all the requests from that email address on hold, and send an email to the user informing the user of Wikipedia's policy on multiple accounts, listing the usernames of the requests we have received from them, and asking which one they would prefer. If there are multiple requests from an email but one of them has been recently closed as created, it's probably safe to drop the remaining requests.

Please keep in mind that shared IP addresses are common. If you have multiple requests from the same IP addresses but different email addresses, and the IP is static, defer to CheckUsers; if it's dynamic or otherwise obviously shared (for example, from a residential or mobile/cellular service provider, or an obviously shared IP like a school or library), continue handling the request (though ensure that you check for on-wiki blocks in this case).

Multiple requests to the tool are only grounds for a ban from requesting accounts in cases of clear abuse. If you have reason to think that an IP or email address has requested multiple accounts abusively, please inform a tool admin for further action. In and of itself, though, multiple requests for accounts are not grounds for a ban from ACC.

In cases where there have been a large number of requests from an IP address assigned to a school or other educational institution, especially if each request has a different email address, there is a "Educational Event or Student Edit-A-Thon" custom close template that by default defers the request to "On-Hold". This close is only intended for use in the case when there have been a large number of account requests from an IP assigned to a school, and we need more information about the desired usage of the accounts. For single account requests, use of the account as part of a school assignment or other educational use is not in and of itself grounds for a request to be rejected or held. If you aren't sure if the "Educational Event or Student Edit-A-Thon" custom close applies to a situation, please ask an ACC admin for guidance.

Please keep these points in mind when dealing with requests made from any kind of blocked IP address or range:

• You should run the other checks first. If there are other reasons that would warrant denial from a blocked IP request, such as a username policy violation or similar username, then you should decline the request for that reason.
• For IP addresses that are locally blocked, refer to § Local IP blocks for further instructions.
• For IP addresses that are globally blocked, refer to § Global IP blocks for further instructions after checking any local blocks.
• If you attempt to verify attributes on your own, such as creating or declining requests based on open-proxy, shared-IP use, etc., you take full responsibility for your actions.
• If you are uncomfortable or uncertain with any request, the safest choice is to defer the request to CheckUsers.

When deferring a request to CheckUsers, Stewards, or proxy check, please include a brief statement on the reason for deferral. This is especially true if you are ignoring part of the guide (such as deferring an older school block).

Do not violate policy by adding any personally identifying information in a request comment – it's generally treated the same as if you did so outside of the interface (due to Wikimedia's privacy and data retention policies). See § Personally identifying information for more information.

Unless otherwise noted in this section, blocks for CheckUser-related reasons, you must defer the request to CheckUsers.

These are blocks that affect a range of IP addresses, rather than just one. This is typically done to partially or completely block networks that can operate using more than one public IP address.

Any range block (affecting any kind of IP address) can be ignored only if any of the following are true:

• The block is an {{anonblock}} or {{school block}}, or is for "simple" vandalism with no specific target (i.e., no specific subject or topic is the target of the vandalism) and there is no vandalism within the prior 72 hours of the request being entered at ACC.
• The block is for disruptive editing with no further details (but if in doubt, ask a tool admin or an experienced ACCer)
• The block is explicitly tagged as being ignorable by ACC (<!-- ACC ignore --> in the block reason)
• The block does not have the "account creation disabled" parameter set.
• The block is placed on an Opera Mini IP range, and solely because of the fact that it is an Opera Mini IP range.
• You placed the block yourself, and you are sure the requester is not the block target.
• The block is a soft (anon. only) CheckUser block for spam and there are no spam concerns from the request.

Any hard (not anon. only) CheckUser block for spam should be declined with the Registered ISP Email or New range email template.

If there is any other range block on the requesting IP (or any indication of sockpuppetry), defer the request to CheckUsers. Users who create accounts from requests that are in such cases and without consulting a CheckUser risk account suspension.

These are blocks that are made to a single IP address, and is commonly done to block single users (such as a residence or network with one public IP address).

Single IP blocks can be ignored if there is a non-recent (i.e., older than 72 hours) block for "simple" vandalism with no specific target (i.e., no specific subject or topic is the target of the vandalism). This includes blocks with the reasons of {{anonblock}} or {{school block}}. The fact that a blocked IP belongs to a school is not in itself an exemption.

If you have a request that you are going to decline or drop due to a single IP block, you need to either:

• be 100% sure that this is the only person on the IP – identifying an IP as static is not sufficient, as multiple users may be connected from the same IP; or
• have approval from a CheckUser or tool admin which is documented on the tool, before you carry out any action.

If you do not have either of these, then defer it to CheckUsers, even if it's already been there.

Check for and address local blocks first.

• Blocks that do not have the "account creation disabled" parameter set can be ignored.
• For IP addresses that are globally hard (not anon. only) blocked (regardless of single IP or range blocks), you should defer the requests to the Stewards.
• Soft (anon. only) global IP address blocks (regardless of single IP or range blocks), can be ignored unless it is believed that the requester is the block target or the block reason is unusual. If in doubt, ask an ACC tool administrator, or defer the request to the Stewards.

Any request from an IP address that is blocked with {{blocked proxy}}, {{webhostblock}}, {{colocationwebhost}} or {{zombie proxy}} as the reason should be deferred to the proxy check queue unless you are capable of confirming that the block reason is still valid yourself. If the request's IP is confirmed to be an open proxy, the request should be closed as "Open Proxy". If there's any indication in the block reason, or if anything comes up in other checks, that suggests that the IP address or range was used for sockpuppetry abuse, the request must be deferred to CheckUsers instead.

Soft (anon. only, with or without account creation disabled) P2P proxy/VPN blocks (e.g., {{blocked p2p proxy}}) can be ignored.

Requests stating that editing via a VPN is necessary should be referred to WP:IPECPROXY using the IPBE for VPN email template.

If there is no block indicating that an IP has been blocked as a proxy, be very careful about using the IP Check service on Toolforge or similar services. These services are frequently incorrect in determining proxy status. While other suspicious network activity may be occurring, unless the IP is static, it rarely indicates anything negative towards the user filing the request.

If you are going to defer to proxy check, have evidence not including the IP Check Service, any site listed on the IP Check Service, and any "proxy checker" website. Proper deferrals include a port number that can be tested for proxies or evidence that the ISP provides access to its own servers (web hosting, cloud services & data storage, colocation & IP transit).

All username requests must follow Wikipedia's Username Policy in order to be created. Please refer to this guideline for any policies and procedures that are not explicitly defined here. Creating accounts that violate Wikipedia's username policy will result in account suspension depending on the severity or blatancy of the username violation. Repeated violations of this rule will result in account suspension.

Where the requested username is a real name relating to famous, popular, etc. person the requester's identity needs to verify through the VRT system. The standard in the username policy is that the name or nickname has to relate to a "specific, identifiable" person. In terms of a test for ACC they should be notable enough to have a Wikipedia article; however, having an article doesn't necessarily mean that they are specific and identifiable and that there is a likelihood that someone is trying to impersonate them. If you believe that they are specific and identifiable and that them having the name may cause confusion, you will need to close the request as "Notable Person". If you aren't sure whether the above test is met, consult with a tool admin or experienced user, it is better to create the account in good faith (remembering that they can be blocked) than to send it to VRT to deal with.

Once VRT has verified the identity of the requester, the requester will be sent back to ACC, either by the request being reopened (if possible) with the VRT ticket number provided as a request comment, or by the requester sending in a new request and including the VRT ticket number in the request comment. However, the request must not be handled until someone with VRT access has verified in the request comments that the VRT ticket contains sufficient proof of the requester's identity and is tied to the ACC request (if you have VRT access, you may do this check yourself; just make a note in the request's comments that you verified that the ticket contains sufficient proof of identity and that the email addresses on the account request and the VRT ticket match). Once the ACC request has been positively tied to the VRT ticket, perform all other standard checks, and if everything looks good, create the account. If you create the account successfully and are a VRT user too, add the {{Verified account}} template to the top of the new user's talk page, including the VRT ticket number tied to the ACC request. If you are not a VRT user but still created the account, please as soon as possible ask a VRT user to add the {{Verified account}} template to the new user's talk page – possible venues for making this request include the VRT noticeboard, #wikimedia-vrt ^connect on IRC, or contacting a VRT user you know directly. Remember to include the name of the user you just created and the relevant VRT ticket number in such a request!

A request containing a VRT ticket number in the comments is not sufficient proof of identity – the validity of any mentioned VRT tickets must be verified by an ACCer with VRT access, with such verification logged in the request comments, before they are accepted!

Requested usernames should only be declined as a username policy violation where it is clear that they are – remember to assume good faith. If you are in doubt, create the account and watch it. If it is engaging in promotional editing, report the user to WP:UAA (as you would with any other promotional username and editing).

If a requested username implies shared use, the request is to be closed because Wikipedia's policy on usernames state that they should not be shared between more than one individual. If you come across a request that implies such, close the request as not created utilizing the "Shared Username" option. This directs them to WP:ISU as well as takes the opportunity to link them to WP:COI, WP:PROMO and more relevant policies or guidelines.

Wikipedia will not allow you to create an account if the requested user name:

A. is a perfect match of an existing global account,

B. too similar to an existing local account, or

C. previously used by another user.

This section will explain the procedures and policies when handling requests that meet one of those two situations.

A perfect match conflict occurs when the requested user name is 100% identical to a username that already exists on Wikipedia (this includes capitalization and use of symbols). If you discover that the requested username is a perfect match, then you must decline the request.

Starting in April 2015, all new accounts that are created result in the creation of a Unified Login across all Wikimedia Projects instead of simply creating a local login to one Wikimedia Project site. To prepare for this process change, all local accounts created before April 2015 whose username was taken on another project were automatically renamed, adding ~<Home Project Site> to the end in order to make them unique across all Wikimedia Projects (see the announcement here to learn more). If the requested username was previously taken but was systematically renamed as part of the preparation for SUL Finalization rule change, it will appear as a log entry and list a username such as "RequestedAccount~enwiki" in the User Page and User Creation Log.

• If the account is taken because someone else has created an account with the exact name first, decline the request as "Taken (Standard)".
• If the account is taken because it is taken but systematically renamed as part of the preparation for the SUL Finalization process change, decline the request as "Taken (SUL Finalization)".

If the requested account is taken, but has a different casing ("Apple" versus "APPLE") or otherwise just appears very similar (not an exact match), then refer to the "Too similar" guidelines below.

A Similar Username conflict occurs when the requested user name is similar, but not 100% identical, to another username that exists on Wikipedia. This typically occurs with requests that would normally be a perfect match to an existing account, but differs with capitalization or the use of symbols or other letters that could resemble the spelling of the existing account (i.e. "Jοhn Doe" vs "Jóhn Đoe" or "J0hn Doe"). These "similar" requests will trip the AntiSpoof extension, and flag the request for additional scrutiny under a separate queue ("Flagged user needed"). Although the ACC tool allows any user to reserve and decline requests in the "Flagged user needed" queue, only ACC tool users with the account creator flag are able to override the AntiSpoof check and create the accounts.

ACC user name requests that are flagged as similar can be created only if the similar existing accounts are determined to be both unestablished and inactive. Similar existing accounts are considered "unestablished and inactive" only if they meet all of the requirements in the Similar Account Flowchart, or meet all of the requirements listed below:

If the similar account has made zero (0) contributions to the English Wikipedia, the similar existing account must:

• Have been created over six (6) months ago.
• Have fewer than fifteen (15) total global contributions.
• Have made their last global contribution over six (6) months ago.

If the similar account has made fewer than fifteen (15) contributions to the English Wikipedia, the similar existing account must:

• Have been created over one year ago.
• Have fewer than fifteen (15) total global contributions.
• Have made their last global contribution over one (1) year ago.
• Have made their last log entry in any Wikipedia logs over one (1) year ago.

If the similar account has made fifteen (15) or more contributions to the English Wikipedia:

• The similar existing account is considered active regardless of the date of the account's creation, last contribution, or log entry.

If a similar existing account fails any of the requirements above, then the similar existing account is active. ACC requests with similar existing accounts that are active must be declined. Decline the request and use the Too Similar close email template. If the similar existing account(s) are inactive, you can go ahead and create the account (provided you are a flagged user). If you do not have the account creator flag, you must break your reservation to allow a flagged user to create the account. Creating such an account should only be done after you have conducted all relevant checks required for any new account request. In order to create the account, you must check the "Ignore spoofing checks" box on the account creation page. This tells the MediaWiki software to ignore any similarity(ies) between the requested account and existing similar account(s), and thus allow the requested account to be created.

AntiSpoof will also trigger when attempting to create an account with a username that was used before another user was renamed.

Do not override this unless the renamed account could be ignored per the § Too similar flow. If you are unsure, contact a tool admin or place the request in the Steward queue.

For the time being, the Russian Wikipedia is directing account requests to ACC for handling in some cases like CAPTCHA issues. In the medium-term future, once multi-domain support (currently in development) is built in ACC, these will be directed to a separate, isolated ACC domain with requests being handled by volunteers from the Russian Wikipedia and not visible to English Wikipedia volunteers. Until then, however, the requests are being directed to the main application with English Wikipedia requests, but the requests will be directed to a separate "Russian Wikipedia requests" queue.

These requests should be handled in the same way as all other requests, following the guidelines outlined in this document, except that requests should be reviewed from the perspective of the Russian Wikipedia (e.g., consulting ruwiki's block log instead of enwiki's), and if an account is created it should be manually created on ruwiki instead of using the built-in OAuth account creation. Likewise, please exercise increased caution when evaluating these requests and use common sense, but there are otherwise no special handling requirements.

For additional context, please see this comment on the GitHub issue.

• When requesters fill out the request an account form, they are given the option to fill a "Comments" field. Any context added is shown in their request, and should be taken into consideration when processing a request.
• If the exact wording of the documentation prevents you from creating an account that you feel should be created, leave a comment explaining why, and break the reservation for someone else to create.
• If your check of the "Creation log" shows that the user created the account themselves, just drop the request, as they don't need to be confused with any of our other messages. Please leave a comment saying they created the account themselves, so that other users know why you dropped the request.
• The requesting user can not see any comments left in the request itself, all comments there will only be visible by other tool users (or only administrators if you choose to mark the comment as "Admin only").
• On "creates" where there are no issues with the request such as vandalism, similar names, etc. there is no need to leave a comment like "Everything looks good with this request".
• If there is a comment on the request asking for, or suggesting, an action and you wish to do something different you must justify this in another comment. If the comment is from a tool admin or CheckUser acting in that position, there must be another comment from a tool admin or CheckUser respectively authorizing you to ignore it. Discussion on IRC is not an excuse, it must be documented on the tool.

If a request reveals through personally identifying information or the comments field that they may have been blocked on another account, proper procedure is to close the request as not created by using the "Block target – appeal" option. This allows the requester to get information on how they can appeal the block on their existing account either through the form of requesting on their talk page, or if unable, emailing the UTRS.

If a request reveals through personally identifying information or the comments field that they may have ties to a company or other entity but the username policy is followed, proper procedure is to close the request as created by using the "COI risk" option. This directly invites the requester to read our relevant policies or guidelines on conflict of interest or promotion. (i.e. WP:BPCA, WP:PSCOI, and WP:PROMOTION)

Once you have reserved a request, and decided that the account should be created, click the Create! link next to the desired username. This will bring you to the MediaWiki account creation form. The name and email will be filled in automatically and the "Use a temporary random password" option will be automatically selected. Do not deselect this option and type in a password. If you do accidentally type in a password and click Create Account, go to Special:Userlogin, type in the username and click Email new password. This will reveal your IP to the requester, so try to avoid doing this. If a message appears – stating the username is forbidden (example here), defer the request to an account creator who can override the Title blacklist using the "Ignore the blacklist" option. Once an account has been created, click Created! next to the request on the ACC tool.

All custom closes should end with an email signature. It is recommended that you add this to your preferences so it is automatically appended to any request closures you perform. If you do not, then you must add your signature at the end of your message every time you custom close a request.

Important things to note:

• If you need to ask the requester a question or confirm information to continue with the request, either click the "Custom" button or click the arrow beside "Custom" to select a standard email template to preload. While waiting for a response, please defer the request to the "On hold" section.
• Unless you are a tool admin, all requests sent from the interface carbon copy (CC) the accounts-enwiki-llists.wikimedia.org mailing list. If the content of your email is sensitive and shouldn't be sent to the mailing list, consider asking a tool admin to handle the request instead.
• If you are responding to an email sent to the mailing list by a requester, make sure you select "reply all" or manually carbon copy (CC) the accounts-enwiki-llists.wikimedia.org mailing list. If you believe the email should not be sent to the ACC mailing list, or if it relates to the actions of tool users, you should carbon copy it to the tool administrator's mailing list, enwiki-acc-adminsgooglegroups.com.
• If you are emailing the mailing list to communicate with other tool users, please list "LIST ONLY" in the subject and text fields to make it clear that the communicate is only to other tool users and not a requester.
• The mailing lists and IRC channel are relatively secure so personally identifying information may be discussed there. However, exercise good practice; if you don't need to share it, then don't do so – linking to a request is a good way to avoid discussing IP addresses and emails without naming them.
• Releasing any kind of private information supplied from the ACC tool, the ACC or admin's mailing list, or the ACC or admin's IRC channel outside of those places is an extremely serious violation and will result in an indefinite suspension. Also, the Foundation takes the tool as seriously as they do with the checkuser tool, as our interface contains similar data available to tool users. Breaching this rule may result in the loss of identified status at meta and the inability to identify in the future. See this email for more information.

Tool administrators (tool admins) are trusted users who can, among other things, edit interface messages (using the Edit! buttons in Message management and Template management), and have access to a fifth option invisible to other users, User management, which allows them to approve, promote, demote, and suspend users. However, abuse of these tools is not tolerated, and the interface is not a toy.

Administrators, in addition to the main mailing list all users are subscribed to, have a private mailing list for discussion of administrative issues of the tool. Any user who wants to appeal a suspension or denial from ACC, wants to report an anomaly with the handling of a request, or otherwise has information they would rather share privately with only the tool admins should send an email directly to that mailing list at enwiki-acc-admins [at] googlegroups [dot] com. Please be patient, as depending on the issue, it may take us a day or two to get back to you.

A list of tool administrators can be found on the tool user list here

The interface developers are the team who have commit access to the tool, and as such can modify the latest development version of the tool in the code repository. If you want something to be changed or added, or find a bug, you can contact one of them, but it's probably better to file a bug in the bug-tracker on GitHub.

The tool roots are stwalkerster and FastLizard4. They have access to the server that runs the tool, and are the only people who can modify the configuration of the tool, and update the tool to a new version. The tool roots also act as the liaison between the Cloud Services administrators, and the rest of the tool users. The tool developers and roots reserve the rights to modify the tool as necessary, and to remove access to the tool for any reason as they see fit.

CheckUsers on Wikipedia will automatically be granted CheckUser-only information and basic administrator capabilities on the tool in order to carry out duties relating to requests requiring a CheckUser. The tool ability is granted by a tool root or another checkuser granting you the "checkuser" role within the user management area.

If there is an urgent need to locate and contact a CheckUser who is currently online and active on Wikipedia, you can do so by requesting the attention of a checkuser on IRC, or by using this tool or this tool to locate a checkuser who is online and currently editing Wikipedia so that you can reach out to them.

• Wikipedia:Request an account/Procedures
• Wikipedia:Technical restrictions on usernames
• Template:ACCbarnstar; the ACC barnstar!
• Template:ACC-access; welcome message for user's whose ACC accounts have been approved.