RoVer now asks users for permission before their Roblox account is revealed to a server or bot. This page explains what that means for members and for server owners.

§Why this changed

To stay within Roblox's policies and to be good stewards of user data, users must now grant access to a server (or a bot) before their Roblox account can be accessed through RoVer or through our API. A user being verified with RoVer no longer automatically means every server they're in can see which Roblox account they are. They decide that for each server.

§What members will experience

Granting access happens as part of the normal server onboarding flow.

If a member is already verified with RoVer from another server, the first time they click Update or run /verify in your server:

• They are given every role they qualify for except the Verified role, and their nickname is not changed yet.
• A message appears asking whether they want their username revealed in that server.
• With one additional click they can grant access. Doing so changes their nickname (if the server configured one) and grants any role bound to Nickname Verified.

If instead it is a member's first time using RoVer at all, and they verify as part of joining your server, granting your server access is built into that verification. Your server is granted access automatically, so they become Nickname Verified right away without a separate prompt.

Members can manage this at any time with the /privacy command, which lets them grant or revoke a server's access explicitly.

§What this means for server owners

Because access is separate from verification, a member may have group roles but not the Verified role. Treat the Verified role as meaning "this member's nickname is verified," not "this member qualifies for Roblox-based roles." If you want to require the Verified role before any Roblox roles are handed out, use the server-wide setting described further below.

§Choosing who a Verified-bound role applies to

When you bind a role to the Verified resource, a dropdown lets you choose exactly which members the role covers:

• Nickname Verified: the member has linked a Roblox account and has given this server permission to see it. This is the standard "Verified" role, and it's the one that drives nicknames. While a member is verified but hasn't granted access yet, RoVer leaves this role exactly as it is (it won't add it and won't remove it) until they decide. You can change that with the removal setting below.
• Unverified: anyone who is not Nickname Verified, meaning they either have no linked account, or they have one but haven't let this server see it yet. It's the exact opposite of Nickname Verified, which makes it ideal for a "please verify or grant access" prompt role.
• Unverified (pre-consent behavior): how the Unverified option worked before consent existed. Matches users who have provided consent, but do not have an account linked.

The pre-consent option is a holdover, so you'll only see it in the dropdown if a role is already set to it, and it can't be picked again once you switch away. In almost all cases it only matches users who were in your server before this change and haven't been updated since, because new members are asked to grant access as part of the process of joining your server.

It avoids a problem for members who were already verified before consent existed: they still hold their Verified role, which is left untouched until they grant access. If the newer Unverified option matched those members instead, they would end up with both the Verified and Unverified roles at once.

§Switching an existing server to the new Unverified option

If your server already has many members who verified before consent existed and haven't granted access yet, they still hold the Verified role. Binding a role to the new Unverified option will also match those members, so until they grant access they will hold both the Verified and Unverified roles at once. There are two ways to handle this:

• Set up your role permissions so that holding both roles is harmless, for example by making sure the Unverified role doesn't take away anything the Verified role grants. Members sort themselves out as they grant access over time.
• Create a new Verified role bound to Nickname Verified, move your verified-only permissions onto it, and retire the old one. Only members who have granted access receive the new role, so unconsented members are left with just the Unverified role.

§Server behavior settings

The Behavior tab of your server dashboard has two server-wide switches that change how RoVer handles access and failures.

§All bindings require privacy consent

Normally, only the Verified role waits on a member granting this server access, while your group, ownership, and other bindings are evaluated as usual. Turn this on and that changes: for a member who hasn't granted this server access, every binding except the Verified-status options is treated as a definite "no." Those roles aren't granted, and are removed if the member already had them.

Use this when you want all of your Roblox-based roles gated behind the access decision, not just the Verified role.

§Remove roles if access is unable to be processed

This is the server-wide version of the per-role "Remove role if access is unable to be processed" checkbox. Sometimes RoVer can't tell whether a member still qualifies for a role. For example, if they deauthorized the RoVer application on the Roblox website, their group memberships can no longer be checked. By default, RoVer leaves the role alone in that situation. Turn this on to remove the role instead, for every bound role at once. (You can also enable it on individual roles in their settings.)

§How these settings interact with the Verified status options

• "All bindings require privacy consent" does not touch the Verified-status options. It forces your other bindings (group, ownership, and so on) to a hard "no" when a member hasn't granted access, but the Verified-status options keep their own meaning. That's deliberate: a role bound to Unverified still matches a member who hasn't granted access yet, so your "please grant access" prompt role keeps working even with this setting turned on.
• "Remove roles if access is unable to be processed" does affect the Verified role. The Nickname Verified option normally leaves the role untouched for a member who hasn't granted access yet, so existing holders keep it. With this setting on (or the per-role checkbox), that pending state becomes a removal instead, and the member loses the Verified role until they grant access. The other two options never produce an "unknown" result, so this setting doesn't change them.

§How /whois is affected

The result of the /whois command now depends on who runs it:

• Server moderators (users who have the Manage Server permission) can view a member's account if that member granted the server access, the same permission that powers the Verified role.
• Regular members only get a result if the target has opted in to appearing in whois queries, which they can do from the /privacy menu.

§Gating a single role without the server-wide setting

If you'd rather gate just one role behind the access grant, without turning on All bindings require privacy consent for the whole server, bind that role with an All of… condition combining Nickname Verified AND your other requirement (such as a group rank). The role then requires both, so it won't be handed out until the member has qualified and granted this server access, while the rest of your roles are unaffected.