Households and portal login

Each household is a family unit on the directory. Open one from Households to edit details, billing, people, activity, and tickets.

Three ways a household comes to exist:

• A member applies through your public join page. Nothing for you to do.

• CSV import — the way to bring a whole roster over from your old system. It shows you exactly what it will do before it does it.

• Add household, on the Households page (manager or super admin). For the family who phoned in, a row an import got wrong, or a household of your own to try things with.

Add household asks for a household name, one adult to contact (name and email; phone and address optional), whether they qualify for your residency priority, and optionally a membership tier. Everything else — the rest of the family, dependents, tags, emergency contacts — is added afterwards from the household's own page.

Two things it deliberately does not do:

• It emails nobody. An address you typed in is not proof that the person holds that inbox, so club email to it is held until they confirm it — the same rule that applies to an imported roster. Ask for that confirmation from Member import, which shows who has confirmed and can send reminders. See Email confirmation.

• It bills nobody. Choosing a membership tier makes the household a member, and that is all: no invoice, no bond, no renewal year. Billing stays something you start deliberately.

Leave the tier as Not a member yet for someone you want on file who has not joined — they are saved as a prospect. If the email address already belongs to someone at your club, the form refuses rather than creating a second household; open the existing one instead.

Adults on the household can sign in to the member portal only if they have a portal login (an auth identity linked to their record). Members (imported or accepted) and applicants (anyone who submitted the join/waitlist application) get a login provisioned automatically. Applicants at apply time, so they can sign in to finish payment and manage their spot before becoming members.

When an adult has no portal login:

1. Open the household → People.

2. Choose Create portal login on that adult.

3. Tell them to sign in at the club portal with the email on their record. Magic-link sign-in uses that address.

Managers and admins can provision. The action is safe to click twice. It will not create a second identity.

This is one person at a time. It does not add a new adult (that is Invite another adult) and it does not change their email (that is Change email, which also changes how they sign in).

Children and other family members on the People tab show as name · child (or adult) · born date. Managers and admins can open Edit on a row to fix a misspelled name, wrong birth date, relationship, or copy-on-message preferences. Saving writes an audit entry. A family member's own email and phone are kept current by the household from their portal Household page.

If it says "This person already has a portal login", that is not an error and nothing else is needed. It means a Swim Ops sign-in already exists for that address — most often because the person is on another club's roster too, or has signed in here before. They sign in with that address as normal, and their record here connects itself the first time they do. Staff cannot connect it for them: a sign-in belongs to whoever holds the inbox, so only that person's own sign-in can prove the connection. If they say the portal shows "that account isn't linked to a member household", ask them to request a fresh sign-in link from this club's own web address and click it once — that is what completes the connection.

Change email can be refused: "This sign-in is used outside this club." The email a member signs in with is one Swim Ops sign-in, not one per club — if they also belong to another club on Swim Ops, changing it here would change how they sign in everywhere, so the platform refuses rather than doing that on one club's say-so. The refusal is recorded in the audit log. Everything else on their record is still editable. Contact Swim Ops support to move a shared sign-in; there is no way to do it from the admin console today.

A bare prospect can't be provisioned. Provisioning is refused for a household that has never applied, isn't on the waitlist, and has no membership — the button won't mint a login for that state. Get them into the pipeline first (apply at /join, or add them via an offer/import). Once a household is an applicant, waitlisted, or a member, provisioning works normally. An applicant or former household that signs in is still not a full member — member-only portal features stay gated until membership is active.

Editing several households at once. On the directory, check the boxes for the households you want (the header checkbox is All on this page), then open Edit several at once. The bar tells you both numbers — households selected and people that will actually change, since a household can hold more than one person — and offers three actions, each opening a dialog with its own settings:

• Add or remove a tag

• Change who we can email or text — the dialog's own choice (turn contact on or off, email or text) is written into its button, e.g. "Turn text messages off." Turning contact on shows a warning instead of a confirmation: only turn it on for people who actually asked to hear from the club.

• Download CSV (selected only) — exports just the checked households; see Exporting the directory below.

Add/remove a tag and the contact-preference change apply immediately — the dialog itself is the confirmation, no extra step. Both are undoable: after any of these, the result banner includes Undo this batch (30-day window; same eligibility as the audit log — see Audit log), and undo is the one action that still asks you to confirm, since its scope isn't visible on screen when you click it. The result banner also says plainly which households, if any, were skipped and why (most often: nobody is on file for that household yet) rather than printing an error code.

Members and family members are now one Person model. Adults with a login and family members without one share the same contact/profile shape. Members keep this current from their portal Household page; staff generally don't need to:

• Birth dates. Every person should carry a birth date. Camp age checks and age-based pricing read them. Adding or editing a family member requires one; adults add their own on the portal Household page, and the portal home reminds households until everyone has one. (People added before this rule keep working until their profile is next edited.)

• Family-member email & phone. Each family member (dependent) can carry their own email and phone, not just adults.

• CC preferences. A second adult or a family member can opt to be copied when the household's primary contact is emailed or texted (a real email cc, or a separate text). See Member not getting emails or texts for how those copies behave.

• Emergency contact. One optional household-level emergency contact. Name, phone, and relationship. This is the source camp registration reads (members enter it once here rather than per registration).

Each custom field has a permanent key used in segments and exports. The Archive/Remove button confirms the consequence: a used field keeps its answers and reserved key while disappearing from forms and segments; an unused field is deleted.

Beyond the built-in contact fields, an org can define its own person custom fields. A "collect once, reuse everywhere" way to track things the platform doesn't model natively (e.g. a swim-team flag, a locker number, a dietary note).

• Manage definitions at /admin/custom-fields (any staff role): create a field (text, number, boolean, date, select/multiselect, phone, email, URL), set whether it's required, whether members see it in the portal, and its order. Options (one choice per line) appear only when the field type is single-select or multi-select. A field's key is fixed once created and its type locks as soon as any value exists. A field that has answers can be archived (hidden, answers kept) but never deleted; an unused field can be removed. Click a field's label in the Active fields list to expand its edit form.

• Members edit portal-visible fields on their Household page (per person), alongside the built-in profile fields.

• Segments can target them. A custom_field predicate is available in a segment's JSON definition (see Campaigns and segments).

• Staff-side visibility today is the CSV export, not the household detail page. The admin household-detail person panels don't yet display or edit custom-field values. To read a member's custom-field values from the admin side, use the directory CSV export (below).

Both live on the household Overview tab under Pause or close this account (at the bottom of the tab, after household details, waitlist, quick links, and notes). Both cut the household off from signing in and from every club email and text. Both ask you to confirm first, and the dialog names the household and how many adults it affects. If the account is already paused or closed, a warning at the top of Overview links down to that card.

• Pause is temporary. Adults cannot sign in and club messages stop reaching them — except a message aimed specifically at paused accounts — until you Reactivate. You can set a date to reactivate on. Nothing is deleted.

• Close is for someone who has left the club. Same effect, no end date; the record, invoices and history all stay exactly as they are, and you can Reopen later. It is refused while a bond refund is still owed (the rule is configured in Settings).

Neither deletes anything, and both are recorded in the audit log. Staff roles keep their access when their own household is paused or closed — the block applies to member access.

Download CSV (current filter) on the directory exports the roster as you've filtered it — one row per member, with household, address, member name, email, phone, opt-ins, and tags. After the fixed contact columns, the export appends one column per active person custom field (header = the field's label), so this is where staff read members' custom-field values today. Those custom values come from the member (adult) row — a value stored on a family member without a login won't appear, and a memberless household exports blank custom cells. Select specific rows first and use Edit several at once → Download CSV (selected only) to export just those. Two guarantees worth repeating to a board: the export contains contact data only — no financial columns ever — and it's capped at 5,000 households per file. Because it's a bulk PII export, the download buttons only appear for manager and super admin roles; treasurer and members don't see them (individual household pages remain visible to all staff).

For the full "getting your data out" picture (camp rosters, treasurer CSVs, statements, the API), see API keys and the public API.