Security & access

How room access works by default

By default, a room has no password and no sign-in requirement — the room code is the key. Anyone with the room's link (or who types its code into "Join a room") can join and vote. There's no participant account to create.

This is the whole access model on the Free plan. Pro accounts can add password, sign-in, and email-domain requirements on top of the code, described below.

Regenerating a room code

If a room's link or code has been shared somewhere it shouldn't have been, an account admin can regenerate it from Dashboard → that room → "Room code."

Regenerating only changes the room's code — its id, votes, queue, history, and all other settings are untouched. The old link stops resolving immediately; anyone still using it needs the new code to get back in.

1. Open Dashboard and select the room.
2. Scroll to the "Room code" card and note the current code shown there.
3. Click "Regenerate code" and confirm.
4. Share the new code/link with anyone who still needs access.

• Preserved: room id, queue, session history, votes, and all room settings.
• Not preserved: the old code — it stops working the moment you regenerate.

Room passwords

A room password is set per room, not per account. It only takes effect when the room's access policy has "Room password" turned on (see account defaults vs. overrides, below).

To set or change one, open Dashboard → the room → "Room access," and enter a value in the "Room password" field. Leaving it blank keeps whatever password is already set. Passwords are hashed (scrypt, salted) before they're stored — SprintBee never keeps a room password in plain text.

There's no dedicated "remove password" control in the room UI today; to require a different or no password, use a per-room policy that doesn't include "Room password," or set a new password.

For participants: when a room requires a password, the join form shows a "Room password" field alongside the room code. If the room's policy also accepts sign-in, participants can use either — a correct password or an approved sign-in both get them in.

Requiring sign-in to join

Turning on "Login required" for a policy means visitors must sign in with SprintBee's email one-time-code flow before they can join a room using that policy.

Two kinds of people are admitted once sign-in is required: active members of the room's account (added from account membership, not this policy), and anyone whose email domain matches the policy's allowlist. There is no way to allow a specific list of individual emails — only whole domains.

On the join screen, a room that accepts sign-in shows a note like "This room requires sign-in with an approved email" (or "Or sign in with an approved email to join" if a password is also accepted). If sign-in is the only way in, the join button reads "Sign in to join."

Restricting by email domain

Email-domain restriction is configured alongside "Login required" — it has no effect unless login is required, since domain matching only applies to signed-in users.

In the policy editor, add one or more domains to "Allowed email domains" (for example, yourcompany.com — with or without a leading @; one per line or comma-separated). Anyone signing in with a matching email domain is admitted, in addition to existing account members.

Leaving the domain list empty while "Login required" is on still works — it just means only existing account members (not arbitrary domain matches) can sign in to join.

Account-wide defaults vs. per-room overrides

Security policies (password / login / allowed domains, bundled under a name like "Internal teams") are created once on the account and can be reused across rooms.

Each account can set one policy as its "Account default," applied to any room that doesn't specify its own. A room's own "Access policy" setting always wins when set: choosing "Use account default" inherits whatever the account default is (or code-only, if there isn't one); choosing a specific policy overrides the account default for that room only.

Precedence, most specific first: the room's own assigned policy, then the account's default policy, then code-only access if neither is set. This is resolved server-side on every join attempt, so changing the account default retroactively affects any room still set to "Use account default."

Which of these require Pro

Every access method beyond the plain room code — passwords, required sign-in, and email-domain restrictions — requires the account's "security_controls" entitlement, which is included on Pro and not on Free.

On Free, the Security tab and per-room "Room access" settings are visible but read-only: existing policies (if any remain from a prior Pro period) still show, but creating, editing, or assigning them is blocked until the account is back on Pro.

Room-code regeneration is not part of this entitlement — it's available on any plan, since it doesn't depend on password/login/domain policies.

Related reading

For the company-wide trust posture behind these controls — encryption, hosting, authentication, and how room passwords and Jira tokens are protected at rest — see the Security page. For how moderator, participant, and viewer roles work once someone is in a room, see Roles & people.