Help Center / Troubleshooting /
Email verification: what it does and does not do
Plutio's verified flag on a user's email is informational. It is not a login gate. A user whose email shows as unverified can still log in normally, and clicking a verification link in an email does not grant login ability that was previously missing. This page explains what the flag actually is, what it does not do, and what really prevents a login when a customer reports being locked out.
What verified is
Every user in Plutio has one or more email addresses stored on their account. Each address is a small object that carries the address itself and a verified boolean, under users.emails[].verified in the database. The flag is true when we have evidence that the person who controls the inbox has interacted with a Plutio email, and false when we do not.
The flag is only written in a few narrow cases:
- Signing in with Google. On the first Google sign-in (and on enrichment of an existing account), Plutio reads the
verified_emailclaim returned by Google and copies it onto the matching entry inusers.emails[]. - Invitations through Auth0. When a user is created from an accepted invitation, the address is marked verified because the invite link itself proves inbox access.
- Changing email address. When a user updates their login email, the new address is stored with verified: false until one of the conditions above applies.
Nothing else writes to this flag. There is no scheduled job that flips it, no support tool that sets it, and no path from a password reset that changes it.
What verified does not do
The most important property of the verified flag is what is not attached to it. On Plutio, verified does not gate login. A user with verified: false on every email address on file can still sign in with their password, still sign in with Google, and still resume sessions from cookies. Nothing in the login flow reads the flag.
Three pieces of the codebase are worth naming, because they are the places that would read the flag if Plutio did use it as a login gate, and none of them do:
- Accounts configuration in
app/imports/api/users/server/config/config.jssetssendVerificationEmail: false, so the Meteor Accounts framework does not auto-send a verification email at signup. The matchingAccounts.validateLoginAttemptin the same file checks only whether the underlying attempt was allowed (correct password, correct handler), never the verified flag. - Two-factor authentication in
app/imports/api/users/utils/2fa/server/login-handler.jsadds a secondvalidateLoginAttempthook and a2falogin handler. It checks password, 2FA state, and 2FA code. It does not reademails[].verified. - Google OAuth in
app/imports/api/users/utils/google/server/login-handler.jsis the only handler that writes the flag (line 134 when enriching an existing account, and on the creation branch when making a new user). Even here, the flag is a result of the successful Google sign-in. It is not a precondition.
In short: verified describes what we know about the inbox. It does not decide whether someone is allowed through the door.
What actually blocks login on Plutio
When a login attempt fails, one of the following is the real reason. None of them is the verified flag.
| Error returned | Cause |
|---|---|
| invalid_login | The password is wrong, the email is not on any account, or the handler rejected the attempt for a generic reason. Plutio intentionally returns one shared error for these cases so the login form cannot be used to probe which emails exist. |
| two-factor-required | The account has 2FA active and the login attempt did not include a valid 6-digit code or backup code. See Two-factor authentication (2FA). |
| incorrect_login_verification_code | A 2FA code or backup code was provided but did not match. |
| pending_invite | The email was invited to a workspace but the invitation has not been completed yet. The invite email has to be opened and the signup flow finished before login will work. |
| Disposable emails are not allowed | Triggered by validateNewUser when an address on a known disposable-email provider tries to sign up. This is a signup gate, not a login gate: once an account exists, Plutio does not re-check the domain on every login. |
| account.suspended_violation | The account has been suspended (typically by the fraud pipeline or by inactivity-deletion tooling). Password validation may succeed, but every authenticated action is rejected and the user is redirected to an "Account suspended" screen. See Inactive account deletion for the inactivity case. |
Those are the gates. Anything outside this list is either a workspace-level permission issue (the login succeeds but a role cannot see a particular area) or an integration-specific error (Google handshake failure, etc.) that surfaces its own message.
"I got an email saying verify your email but still can't log in"
There is one Plutio email that causes confusion here. During signup, Plutio can send an email with a 6-digit verification code. If that code has arrived but login is still failing, the situation is almost always one of these two:
- The code is completing a signup, not unlocking a login. The 6-digit email is sent when
user.emailVerification.isPendingis set on a partially-created account. Entering the code finishes the signup (it inserts the workspace person record, or lets a new workspace be created) and clearsemailVerification. It does not touchusers.emails[].verified. Once the signup is complete, the field is unset and nothing checks it again. If login still fails after the code is accepted, the underlying cause is one of the five gates in the previous section, not the code itself. - A generic "please verify your email" message does not exist on Plutio. Meteor's built-in verification email is disabled (
sendVerificationEmail: false). So if a customer describes receiving a generic verify-your-email message and blames it for a blocked login, either the email came from the signup flow above, or it came from a different service using the same email address.
Clicking any link in a Plutio email never by itself enables future logins. Either a signup is being completed, or the flag is being updated in passing, and neither of those creates or removes login ability.
When verified is actually useful
The verified flag is still worth looking at, but as a support signal, not as a login diagnostic.
- Ownership check. If a user's primary email shows
verified: true, it is strong evidence that they controlled the inbox at some point (they logged in with Google for that address, or accepted an invite sent to it). - Deliverability clue. A long-running account with every address
verified: falsehas never signed in with Google and was never created through an invite. That narrows where outgoing notifications have been delivered historically. - Cross-reference with fraud tooling. Verified true + activity from the expected region is a positive signal; verified false + signup-time flags is neutral, not a red flag on its own.
Never use the flag to answer "why can't this user log in?". The answer to that question is always in the five gates above, plus the workspace-level permission rules described in Users and team management.
If a user says they can't log in
When a customer reports that they are locked out, work through these checks in order before doing anything else. The verified flag is deliberately absent from the list.
- Is the email on file at all? If not, the error is
invalid_loginand the next step is the password reset flow so they can type their email into the "Forgot your password?" form and see whether a reset arrives. - Is 2FA active on the account? If it is and they no longer have the authenticator app or their backup codes, a proof-of-ownership reset through help@plutio.com is the only path back in. See Two-factor authentication (2FA).
- Is there a pending invite for this email? A user with
pending_invitestatus needs to finish their invitation rather than log in. The original invite email contains the signup link; resend it from the admin who invited them. - Is the account suspended? A suspended account can "log in" but lands on an account-suspended screen. This is the fraud or inactivity pipeline acting, not a login problem. Treat it as an account-status question.
- Is this a workspace-level permission issue? If login succeeds but a specific area is empty or read-only, this is a role or per-entity permission issue, not an authentication one. See Custom roles and permissions and Per-entity permissions.
Running through these in order resolves the vast majority of "I can't log in" tickets without ever needing to touch the verified flag.
