Organization Onboarding
A step-by-step guide for organization administrators getting a new club ready in Hearth & Hall.
Use this after your organization exists in the product. Today, a Hearth & Hall platform operator creates the organization and works with you through concierge onboarding (personalized setup — not a self-serve signup). Before members can use the organization, someone with Accept Terms of Service permission (terms.accept) must accept the current Terms in the product (hard gate) — typically an Admin, or an officer role such as President that was granted that permission. Creating the org does not count as acceptance, and Hearth & Hall platform operators cannot accept on behalf of your club. Self-serve club signup may come later — the configuration steps below stay the same.
What you get on day one
When the organization is created, Hearth & Hall seeds:
| Seeded item | Purpose |
|---|---|
| Organization | Name + URL slug (used in routes such as /orgs/{slug}/…) |
| Founding membership type | One roster type (default name Member, overridable at org create) with the Member role as baseline |
| Your Admin membership | The creator is active on that founding type with the Admin flag |
| Seeded role | Member only — everyday participate permissions |
Nothing else is configured yet — no Certificate Holder / Guest / Board / Treasurer concepts, no reservation catalog, no other members. As Admin you create the membership types and officer roles your club needs.
How access works
Hearth & Hall uses roles and permissions rather than a single fixed rank:
- Each membership has an Admin on/off flag. Admins have every permission in the organization.
- Permission keys are fixed by Hearth & Hall (billing, catalog, documents, …). Orgs do not invent keys.
- Everyone else gets permissions from the roles they hold. You name roles for your club (Board, Treasurer, Hospitality, …) and attach the keys each role needs.
- A membership can hold zero or more roles. Roles come from two places:
- Type baseline roles — every membership of a type automatically gets that type’s baseline role(s). The founding type starts with the seeded Member role; attach baselines when you create more types.
- Assigned roles — officer/committee roles you create and assign to individual members from the roster.
| Role | Who defines it | Typical use |
|---|---|---|
| Member (seeded) | Platform starter | Directory, book/cancel own reservations, add family members |
| Your officer roles | You (Admin) | e.g. Board → catalog/events/documents; Treasurer → estimates/invoices |
| Admin flag | Membership setting | Everything (superset of all roles) |
Hold Admin yourself for setup. Create Board / Treasurer (or whatever names your bylaws use), grant them the right permissions, then assign colleagues so catalog and billing can proceed in parallel.
Checklist overview
- Sign in and open the organization
- Accept the Terms of Service
- Review membership types
- Create officer roles and grants
- Invite officers and primary members
- Build the roster (family / sub-accounts)
- Configure the reservation catalog
- Prepare billing
- Optional: forums, mailing lists, events, and documents
- Smoke-test before members arrive
1. Sign in and open the organization
- Open the member app (
members.in production; local UI in development). - Sign in with the account that was made Admin when the org was created (or the Admin Hearth & Hall assigned to you).
- If you have not set a password yet, complete Set Password when prompted. If you forgot an existing password, use Forgot Password? on the sign-in page.
- Use the context switcher in the header to select your organization.
Until Terms are accepted, members cannot use organization features. Anyone with Accept Terms of Service sees a blocking accept screen; other members see that the organization is not activated yet. After acceptance, navigation is org-scoped: Members, Forums, Mailing Lists, Email Members, Events, Documents, Reservations, Billing, and Reports when granted.
2. Accept the Terms of Service
Who: Anyone with Accept Terms of Service (terms.accept) — organization Admins always have it; you can also grant it to an officer role (for example President) under Members → Roles.
- Read the Terms (and linked Privacy policy) presented on the accept screen — the screen shows the revision you are accepting; full text also lives on the public site (
www./terms) with the same revision. Accepting the Terms also accepts the then-current Platform Pricing Agreement (public Pricing page), unless your club has a written pricing override with Hearth & Hall. Fee tables are not copied into the Terms; they are linked from them. - Confirm you have authority to accept on behalf of the organization.
- Accept the current revision. The product records which member accepted, which organization, which revision, and when (for support and audit).
Members cannot use the organization until this is done. If Hearth & Hall publishes a new Terms revision later (including when platform pricing changes — with advance notice), someone with Accept Terms of Service must accept again before the organization unlocks, unless counsel later adopts a different notice-only process for some updates.
Platform operators: Hearth & Hall staff who created your organization can help set up roles and invites, but they cannot accept Terms for you — a club member with the permission must do that.
3. Review membership types
Where: Members → Membership Types (Admin only)
Membership types are your dues / roster / pricing classes. Hearth & Hall does not ship club-specific type names (Certificate Holder, Guest, …) — you create what your bylaws need. Day one includes only a founding roster type so the first Admin can exist; rename it and add more types as needed.
Capabilities such as booking, voting, and adding family members come from roles, not type checkboxes. Attach the seeded Member role (or others) as baseline roles on each roster type.
Suggested types (examples — create these if they fit your club)
| Example name | Typical use | How members are added |
|---|---|---|
| Provisional / Certificate Holder | Primary members who sign in | Invite Member (Requires Email on) |
| Active / family | Linked household members under a primary | Add Family Member (Requires Email off, Requires Primary Account on) |
| Staff / Steward | Operators who sign in but are not club members | Invite Member (Requires Email on, Staff Member on); omit Member baseline unless you want self-book |
| Guest Adult / Guest Child | Pricing only — not roster memberships | Never invited; used when booking a named guest (On Roster off) |
Configure each type
| Setting | What to decide |
|---|---|
| Name / Description | Labels members and staff will recognize |
| On Roster | Off = pricing-only (no roster row / no baseline permissions unless you attach roles); on = real membership rows |
| Requires Email | On → Invite Member; off (with roster on) → Add Family Member |
| Requires Primary Account | Linked sub-account under a primary (typical for children / household members) |
| Staff Member | On = operator / steward accounts: hidden from the default Members → Roster (use Include Staff to show them), excluded from “all members” email and announcement blasts, and not offered as book-for subjects on Reservations → Book (staff book for club members via reservations.create.for-member, not as reservation subjects themselves). Still invited with email and still count as platform primaries when they are primary accounts. Requires On Roster. |
| Baseline Roles | Which roles every member of this type receives (founding type starts with Member; staff types usually omit it) |
| Active | Deactivate instead of deleting if the type is already referenced |
Tips
- Match names to your bylaws.
- Keep at least one pricing-only type (
On Rosteroff) if non-members book resources. - Prefer deactivate over delete when a type is already used on members, prices, or reservations.
- For stewards: create a Staff type, create a Stewards role (§4), invite with that type, and assign the Steward role.
4. Create officer roles and grants
Where: Members → Roles (needs members.roles.assign, which Admins always have)
Only Member is seeded. Create the officer hats your club needs before inviting colleagues who should not be full Admins.
Suggested starter roles (names are yours — match your bylaws):
| Role name (example) | Grant these permissions (examples) |
|---|---|
| Board | resources.catalog.manage, events.manage, announcements.create, forums.categories.manage, mailing-lists.manage, mailing-lists.send, documents.manage, members.roles.assign, reservations.cancel.any, reservations.create.for-member, reservations.create.guest, reservations.reprice, audit.view |
| President (optional) | Often includes terms.accept (and broad leadership keys) when the club wants the President — not only Admin — to bind the Terms |
| Treasurer | billing.estimates.manage, billing.invoices.send, billing.invoices.view-all, audit.view |
| Stewards / Hospitality (example) | reservations.create.for-member, reservations.create.guest, reports.day-sheet.view (and cancel/reprice keys if they should adjust holds). Assign to people on a Staff membership type (§3), not the founding Member type. |
You can add committees (Hospitality, Property & Grounds, …) the same way — create a role, attach keys, assign people.
Audit Trail: Admins (and any role granted audit.view) can open Audit Trail in the top nav to review who changed security-sensitive, financial, and document records.
Reports: Grant reports.day-sheet.view on your Steward / Hospitality role so those members see Reports → Day Sheet. The Day Sheet lists day-of reservations (meals, lodging, tee times, boats, …) for kinds and resources marked On Day Sheet in Catalog Setup — turn that off for items like service fees. Staff can print a day (or 3-day / week) sheet, mark attendance on paper, then update open tabs from Reservations → Book or Billing. The report itself is read-only.
5. Invite officers and primary members
Where: Members → Roster → Invite Member (needs the invite permission; Admins always have it)
- After officer roles exist, invite colleagues so catalog and billing can proceed in parallel.
- For each invite, choose:
- Name — how they appear on the roster (they can refine this when accepting the invite)
- Membership type (a roster type you created for adults who sign in)
- Roles — optionally assign the officer roles you created (e.g. Board, Treasurer). These attach to the pending membership and carry through when the invite is accepted.
- Organization Admin — check only for full administrators.
- The invitee appears on the roster as Pending immediately.
- They open the invite link, complete signup / password, and become Active.
- You can assign roles on the invite (step 2) OR after they accept — open their roster row → Edit.
Assigning access for a new club
| Give them… | So they can… |
|---|---|
| Admin flag | Manage types, invites, roles, and membership details — full access |
| Your Board-style role | Whatever you granted (typically Catalog Setup, events, documents, …) |
| Your Treasurer-style role | Whatever you granted (typically estimates & invoices) |
| Member role (baseline) | Everyday member features — comes automatically with roster types |
You remain Admin. Do not remove the Admin flag from (or deactivate) the platform operator’s membership if Hearth & Hall provisioned the org for you — that account stays tied to platform support.
6. Build the roster (family / sub-accounts)
Where: Members → Roster
After primary members are active:
- Primaries whose role grants sub-account creation (the Member baseline role does) — or Admins — use Add Family Member for household members who do not need their own email yet.
- Capture relationship (Child, Parent, Partner, Spouse) and optional birth date (used for child vs adult rate brackets when booking).
- When a family member is 18+ and should sign in themselves, send a Sign-In invite from the roster.
Billing note: Only primary members are billable. Charges for a linked sub-account resolve to the primary’s open tab / invoice.
7. Configure the reservation catalog
Where: Reservations → Catalog Setup (requires resources.catalog.manage, or Admin)
Do this before opening booking to the membership. Work kind → resource → rules → prices.
6a. Create resource kinds
A kind is a category of bookable thing (lodging, meals, boats, courts, …).
- Create Kind.
- Set Details: name, booking mode, icon, Active, and On Day Sheet.
- Interval — date/time ranges (e.g. lodging nights, equipment hours)
- Fixed Slot — grid of slots (e.g. tee times, meal seatings)
- Quantity — pool of units (e.g. boat inventory)
- On Day Sheet — include this kind on Reports → Day Sheet for hospitality staff (leave off for pricing-only items like service fees)
- Open Schedules and define when that kind is generally available (weekly windows, seasons, blackouts). Mark a default schedule.
- Open Policy — lead time, duration limits, cancel-before, capacity-related limits. (Who may book is governed by the booking permission on a member’s roles, not a per-policy minimum role.)
- Open Pricing — default and optional per membership type rates (Flat, Per Hour, Per Night, Per Slot). Add Guest / child rates if your club uses them. Optional effective date ranges for seasonal prices.
6b. Create resources under each kind
- Select the kind → Create Resource.
- Details: name, capacity (for fixed-slot party limits), Active, On Day Sheet, optional schedule inheritance vs custom.
- Availability: inherit the kind’s default schedule, pick another kind schedule, or override with resource-specific rules.
- Price: optional resource-level overrides when one instance differs from the kind default.
6c. Verify booking paths
From Reservations → Book:
- Book a test hold for yourself (and a guest if applicable) on the person × date × resource grid.
- Confirm quote / estimate lines look right for membership type and age bracket.
- Confirm cancel behavior matches policy.
Deactivate kinds or resources that should not accept new bookings; delete only when nothing references them.
8. Prepare billing
Where: Billing (billing permissions, or Admin)
- Ensure at least one person has your billing role (or is Admin) and can sign in.
- Confirm reservation booking creates / updates the member’s open tab (draft estimate) when prices are configured.
- Practice the billing loop: review estimates → convert to invoice → Send (emails the bill-to member a billing link to pay or download a PDF) → member pays with a saved card (when payments are enabled for your environment). Use Download on any invoice for the PDF. Someone with Send Invoices (or Admin) can Refund a paid or partially paid invoice from the invoices table.
- Someone with View All Invoices (typical Treasurer grant, or Admin) can use Billing → Export to QuickBooks to download invoices and payments for a date range.
- Member history & profile: members open My Profile (click their name or avatar in the header) to see household invoice and payment history — not only under Billing — and optionally set a photo and a short About Me note. Linked family accounts bill to the primary and see that household’s history with a billed-to note — see the billing note under Build the roster.
- Payout setup (Stripe Connect): member dues settle to the club via Stripe Connect, not to Hearth & Hall. Someone with Send Invoices (typical Treasurer grant, or Admin) opens Billing → Organization Payouts, starts Stripe’s hosted onboarding (identity + bank), and returns to Billing when finished. Use Refresh Status if the page does not update on return. Members may save a card on file before payout setup is complete, but Pay stays blocked until Stripe reports the connected account can accept charges.
Never enter club bank account or card PANs into Hearth & Hall forms outside Stripe-hosted or embedded flows — the product stores tokens only.
9. Optional: forums, mailing lists, events, and documents
Configure these when your club is ready to use them; they are not required to open reservations.
| Area | First actions |
|---|---|
| Forums | Create categories members will recognize; pin welcome threads if useful. Each category has an All Members switch — turn it off to pick the specific roles that may view/post in the category (leave the role list empty for Admin only). Admins always see every category; creating/editing categories needs forums.categories.manage |
| Mailing Lists | Create a saved audience (e.g. “All Members”, or a membership type / org role filter). The All Members audience switch controls who receives messages; when off, pick a membership type or role. Staff membership types are never included in “All Members” audiences (so membership-only topics such as compensation stay off staff inboxes); target a staff type or role explicitly when you need to reach operators. The separate All Members Can Manage access switch (+ role picker) controls who may use the list. Creating/editing lists needs mailing-lists.manage |
| Email Members | Compose subject/body, pick an audience (all members, admins, membership type, role, or saved mailing list), review the recipient list (name and email) for that audience, then send. “All members” excludes staff types (same rule as mailing lists). Messages send from the platform address; replies go to your personal email (Reply-To). You need an email on your account before you can send. Needs mailing-lists.send (and list ACL when targeting a saved list). Send history shows subject, audience, count, and time |
| Events | Create upcoming club events; confirm registration / waitlist behavior |
| Documents | Create folder tree (bylaws, minutes, forms); set each folder’s access with the All Members switch — turn it off to pick the specific roles that may open the folder (leave the role list empty for Admin only). Admins always see every folder; creating/editing folders needs documents.manage |
10. Smoke-test before members arrive
Work through this as Admin (with officers who hold your catalog/billing roles if needed):
- Membership types match how your club actually admits people
- Officer roles exist with the right grants; at least one catalog officer and one billing officer can sign in (or you stay Admin for both)
- A primary invite accepts and reaches Active
- A family member can be added under that primary
- Catalog has every kind members will book, with schedules and prices
- A test reservation quotes the expected rate and lands on the primary’s tab
- Someone with billing permissions can convert / send an invoice on the test path
- Forums / mailing lists / events / documents are ready enough for launch day (or intentionally deferred)
Access at a glance
The Admin flag is a superset — it grants everything regardless of roles. A member can hold several roles at once; their access is the union of those roles’ grants.
| Capability | How you get it |
|---|---|
| Everyday member features | Seeded Member baseline on roster types |
| Catalog, events, documents, forums, mailing lists, cancel/reprice any | Role you create + grant (e.g. Board) — or Admin |
| Estimates & invoices | Role you create + grant (e.g. Treasurer) — or Admin |
| Membership types; update members; create roles | Admin (or roles you grant members.types.manage / members.update / members.roles.assign) |
After go-live
- Invite remaining members in waves; keep Pending visible on the roster until they accept.
- Adjust prices and schedules seasonally without rebuilding the catalog — use effective dates and schedule seasons where available.
- Deactivate obsolete types or resources rather than deleting history.
- Contact Hearth & Hall support (or your platform operator) for org rename / slug changes and production payment go-live.