GCM Docs

Appearance

Recovering a locked-out user ​

Sooner or later, someone will get locked out — a forgotten password, an active toggle flipped off in error, an Administrator who accidentally stripped their own users.manage permission. This article walks through the recovery path for each case, in order of severity, ending with the last-resort intervention from the GCM team.

The good news: in nearly every scenario, a working second Administrator can fix the problem from the UI in under a minute. The bad news: if your workspace has exactly one Administrator and that's the locked-out person, the recovery requires our team. The mitigation is simple — keep at least two Administrators at all times.

TIP

This article assumes the user knows their email and is on a normal device. If the device itself is compromised, see your church's incident response process first; restoring sign-in to a stolen laptop just makes things worse.

Case 1: Forgotten password (most common) ​

The user enters the wrong password three times in a row and the sign-in page asks them to Reset your password. They click that link, type their email, and hit submit. GCM emails them a one-time link valid for 1 hour; clicking it opens a Set new password screen, after which they can sign in normally.

If the email never arrives:

  • Check the spam folder.
  • Confirm the email on file is current — an Administrator can look it up in Users & Roles and edit if needed.
  • Look in Settings → Data Logs for an auth.password_reset_requested entry; if it's there, our mail gateway accepted the message and the issue is downstream (the recipient's inbox).
  • If still nothing, an Administrator can use the force-reset option described below.

Case 2: Admin force-reset ​

Another Administrator can override the password directly. Open Users & Roles, click the user's row, type a new password into the Set password field, and save. The user is signed out of every session and must use the new password to sign back in. Hand the password over via a side channel (verbal, signed message) — don't email it.

This same flow works if you suspect a password has been compromised: rotating it via force-reset terminates every active session for that user.

Case 3: Suspended account ​

If the active toggle on the user's profile got flipped off, they'll see Your account is suspended on the sign-in screen even with the right password. An Administrator opens the user, flips Active back on, saves. They can sign in immediately — no email, no link.

A common cause: someone confused the Suspend and Delete buttons, or the user was suspended during a billing downgrade and never restored. Both are reversible from the same dialog.

Case 4: User has roles but the wrong ones ​

Most often this looks like I can sign in but every page says permission denied. Two sub-cases:

  • The user has no roles at all. Open their profile, click the Roles button, pick at least one (usually Leader or Viewer to start), save. They get the new permissions on the next page load.
  • The user has a role but it doesn't grant the keys they need. Either grant more keys to the role (affects every user with that role) or assign them a second role. See Granting permissions and Default roles for guidance.

Case 5: The only Administrator is locked out ​

This is the case to plan against. If you have exactly one Administrator and they can't sign in, no one in your workspace can change roles, reset their password from the UI, or even open the Users & Roles page. The recovery is:

  1. Try the password-reset email flow first. It's the fastest path and doesn't require our intervention.
  2. If the email never arrives — or if the locked-out user is unreachable — email info@geniuschurchmanager.com from a verifiable address (typically the workspace's billing contact). Include the church name, the workspace URL, and a description of the situation.
  3. A platform admin from the GCM team will perform a signed impersonation session, enter your workspace, and either reset the password directly or promote a second user to Administrator so you can take over from there. Every action is logged in platform_audit_log and visible to you afterwards. The session expires automatically; we don't keep persistent access.

This path exists precisely so you never lose access permanently, but it's slow (typically a few hours during business hours; longer overnight or on weekends) and requires identity verification. The fix is to never run on a single Administrator.

WARNING

GCM has no "reset Administrator via SMS" or "magic link from billing email" path. Anything that bypasses our verification process would also bypass the verification a determined attacker could use. The platform-admin route is intentionally slower and requires human review — that's the security feature.

Prevention checklist ​

A 30-second checklist that prevents the most painful lockouts:

  • [ ] At least two Administrators on every workspace.
  • [ ] Both Administrators have a working email and recovery option.
  • [ ] The billing contact is a real person who reads their email.
  • [ ] At least one Administrator's email is at a domain you control (not a free personal address that could be lost).
  • [ ] Never strip users.manage from every Administrator role — keep it on the seeded Administrator role even if you're locking down a custom one.

If you ever need to test the recovery path, do it on a sandbox workspace, not production. We can spin one up for you if you ask.

Next ​