Member can't sign in / never got the magic link

Symptom-first guide for the most common member-facing login complaint. Sign-in is passwordless: a member enters their email at the login page and gets a 15-minute magic link. There is no password to reset.

A common cause: the person doesn't have a portal login yet. An email being on the household record does not by itself mean that person can sign in. A portal login (an auth identity linked to their record) has to be provisioned.

Who already has a login (provisioned automatically):

• Members (imported or accepted through an offer).

• Applicants: anyone who submitted the join / waitlist application now gets a login provisioned at apply time, so they can sign in to finish or resume payment and manage their spot without waiting to become a member. (This closed the old dead-end where an applicant who abandoned payment had no way back in.)

Who can't be given one: a bare prospect — an imported lead or contact with only an email on file who has never applied, is not on the waitlist, and has no membership. Provisioning is refused for that state; there's no login to hand out until they enter the pipeline (apply, get waitlisted, or become a member). Don't keep clicking Provision for a true prospect. Get them to apply instead.

The login page always says the same thing after a submit. "If [email] is on file, a sign-in link is on its way": whether or not that address actually matches anyone. This is deliberate (it stops the login page from being used to check who is or isn't a member), so "it said it sent it" does not confirm a login exists.

Resolution:

1. Open Households, find the person, go to People.

2. If they're a member or applicant and have no login yet (or a provisioning attempt may have failed silently. See When to escalate), use Provision portal login: see Households and portal login. If they're a bare prospect, provisioning won't work; have them apply first.

3. If they already have a login, the email likely landed in spam or Promotions. Have them check there and add the sending address to contacts.

Suggested wording: "I've checked your record — you didn't have portal access set up yet, so no email would have come through. I've turned it on now; please try the sign-in link again and check spam if you still don't see it."

Some people are on the roster of two clubs. A family that belongs to two pools, or a staff member who helps run both. That is supported: sign-in resolves against the club whose web address they are signing in on, so the link they get is for the club they were looking at, and it lands back on that club's site. Signing in at the other club's address gets them the other club's link. Nothing needs to be configured for this.

The consequence to know when someone says the link never arrived: a sign-in request only produces a link if that address is on this club's roster. If they are a member of a different club and typed their address at your login page, they get the same "if that address is on file, a link is on its way" message and no email. The page cannot tell them (or anyone probing it) which clubs they belong to. Check whether the person is actually on your roster in Households → People before chasing a delivery problem.

Suggested wording: "Each club has its own sign-in page, and the link only works for the club you request it from. Make sure you're on [our address] when you ask for the link. If you're signing in at another pool, request it there instead."

The member does have a session (they clicked a real, unexpired link), but the banner on the login page reads: "That account isn't linked to a member household." This happens because sign-in resolves to an internal identity record, and that identity has never been linked to a household member row, most often after a Google sign-in from an address that was never provisioned, less often a magic link into an orphaned identity.

Resolution: this is the same fix as above. Use Create portal login for the correct household member from People. Provisioning links the existing identity to the member record; it does not create a duplicate, so it's safe to run even if you're not sure whether one already exists.

Suggested wording: "That message means your login isn't linked to your household yet, not that anything is wrong with your account. I've linked it now: try signing in again."

This is expected, not a broken account. An applicant (someone who applied but whose household isn't a member yet) can sign in and use a limited set of surfaces, the portal Home with their application/waitlist status, their Household contact info, Activity, and Contact us, but member-only features are gated off until the household becomes a member. Camp, lap swim, guests, events, parties, the shop, the Membership hub, renewal, and relinquish all redirect an applicant back to Home; invoices, statement, and documents turn applicants away too. (A former member keeps read-only access to their invoices/statement/documents, but not the member actions.)

The applicant's own menu reflects this, they see Home · Status · Activity · Contact, not the full member menu, so if an applicant asks where a member feature went, the answer is that it unlocks when their membership is active, not that something is misconfigured.

Suggested wording: "While your application is still in progress, your account can see your status and update your household details, but things like camp registration and renewal open up once your membership is active. You'll get those automatically at that point. Nothing extra to set up."

This is the app's rate limiter: 5 sign-in requests per 15 minutes for the same email at this club, and 20 per 15 minutes from the same network/IP (covering a whole household or building requesting at once). Past the limit they'll see "Too many sign-in requests. Wait a few minutes and try again."

The per-email limit is counted per club, so someone else requesting links at a different pool cannot use up your member's allowance. There is also a higher platform-wide ceiling on a single address across all clubs, which only a script would ever reach.

Resolution: confirm it's the limiter (the message above) rather than a real delivery failure, and ask them to stop retrying and wait roughly 15 minutes before the next attempt. Retrying faster only keeps the window open.

Suggested wording: "You've hit our sign-in rate limit from requesting several links quickly. That's a safety measure, not an error. Please wait about 15 minutes without clicking send again, then try once."

The platform supports alternate sign-in emails: a member can add a verified alias address (e.g. a spouse's inbox) so the magic-link email delivers there, while the underlying sign-in identity stays the original address. This is self-service. The member sets it up themselves in the portal under Household → "Add another email for yourself", not something staff configure from the admin console.

If a member says "I'm using my spouse's email and it doesn't work":

• Check whether they've actually added and verified that address as an alias in their own portal settings (a pending, unverified alias won't deliver).

• If they haven't set one up, they can add it themselves at Household → "Add another email for yourself" in the portal, or they can simply sign in with the original account email instead.

Suggested wording: "Alternate emails have to be added and verified from your own account first. Go to Household → "Add another email for yourself" in the portal to add [address] there, and it'll start receiving the link. Until then, sign-in still works with your original email."

Two different causes, both look like "Google is broken":

• Button not showing at all: Google sign-in is not configured for this environment (a Google client credential or the OAuth relay secret is missing: these are engineering/deploy settings, not something in the admin Settings screen). The button hides itself rather than showing an error. This is expected until Google sign-in is set up, not a bug on the member's end.

• Button shows, but signing in with a personal Gmail address fails/lands on "no account": the Google identity isn't linked to a member record. Same fix as the "no account" case above: provision portal login for that person from People, using the email their household record actually uses.

Suggested wording: "Google sign-in only works once your account is linked: I've done that now, please try Continue with Google again." (Or, if Google isn't set up for the club at all: "We don't have Google sign-in turned on yet. Please use the email sign-in link instead.")

"I saw a different web address while signing in — is that a phishing site?" No, and this is worth answering plainly because it looks alarming. Google sign-in passes through a Swim Ops address beginning auth. on its way back to your club's site. It is there so Google only ever has to know one address for the whole platform, which is also why a club on its own domain needs no Google setup at all. The member ends up back on your club's own address, signed in. If someone reports being left on the auth. address rather than passed through it, that is a real fault. Escalate it.

Known gap: the underlying auth library's send-magic-link endpoint will mail a link to any syntactically valid email address, regardless of whether it belongs to a member. Sign-up is supposed to be fully disabled, but that restriction is only enforced when the link is actually clicked, not when the email is sent. The app's rate limiter is the only thing bounding how many of these can go out.

This is a nuisance, not a security hole: if that address doesn't match an existing member, clicking the link is a no-op. It cannot create an account or grant access to anything. Reassure the person the email doesn't mean they're on file or that anyone can now see their data.

Suggested wording: "That's a known quirk of our sign-in system — it can send a link to any email, but the link doesn't do anything unless that address is already a member. It's safe to ignore or delete."

Provisioning a portal login normally works immediately and is safe to retry. But if a member insists they still can't get in after you've confirmed a portal login was provisioned and rechecked spelling/spam, don't keep re-clicking Provision. A provisioning call can fail silently in the background, and there is no automatic retry: recovery is a manual backfill script an engineer runs by hand. Escalate to an admin/engineer rather than telling the member to "just wait," since nothing will automatically fix it.

Also escalate:

• A member insists they were never a duplicate/never re-applied, but two household records seem to exist for them. Don't merge or delete records yourself.

• Any report that sounds like actual unauthorized access (someone else's data visible), rather than an inability to get in.