Team Members

One list of everyone who works here — office, sales and every crew — whether or not they have a login, with role, crew and permissions editable in place.

What it is

The Team Members tab reads the same roster the Team page draws its cards from: the union of crew members, sales reps, the org membership mirror and Clerk accounts, folded so one human is one row. Each row shows name, role and contact, with an inline editor for details, crew, role, their work record and app permissions.

Also called: who works here · staff list · employee list · user accounts · add a person

See it
Team Members
CustomerBuildingAmountStatus
Ivy BrubakerBarndominium$10,320Open
Ronan PetschBarndominium$9,370Paid
Gideon AltHobby Shop$5,950Sent
Sutter KlineEquipment Storage$12,980Open
Marlin HooverBarndominium$8,800Sent
Team Members with Office / Sales / crew sections, two-to-three cards across, one row expanded into the editor. SettingsView.tsx members tab. Sample data — no customer information appears here.
How it works
  1. 1The tab loads /api/team/roster, which resolves people through lib/orgRoster and returns name, role, crew, sources and whether they can sign in.
  2. 2Rows are grouped into Office, Sales, one section per crew, and Not on a crew.
  3. 3Editing writes to whichever store owns the person: /api/team/member for a crew or rep row, /api/users/[id]/role for someone with a Clerk account.
  4. 4A header count says how many people there are and how many of them have a login.
Why we built it

Quoted in the file: “Under the team members tab in the Ridgeline sub-account there's nobody there. When I go to Team, I see 3 different crews of people plus salespeople… are these not supposed to be directly connected?” They were, and they weren't — this tab listed Clerk accounts on top of a browser-local array while the Team page listed the roster union. On Ridgeline that was 0 against 19. The comment names the failure mode: “the same question asked twice and answered differently, which is the failure mode this codebase keeps having.” Both surfaces now read the roster.

The problem
  • Two screens answered who works here with different numbers.
  • Field labour with no login was invisible in Settings.
  • A browser-local copy of the team list survived long enough to show a stale list after someone was removed elsewhere.
Sound familiar?
What you get
One roster answer everywhere in the product.
Field crew and sales reps without logins are still real, editable people.
A removal or role change on one device is the truth on every device.
What's inside
Roster grouped the way the company is
The staff list is split into Office, Sales, one section per crew and Not on a crew, with leaders first inside each crew.
Edit a person in place
Expand any person's card to edit their name, email, crew and role, see their work record, and set app permissions if they have a login.
Saved / save failed confirmation on every edit
Each person's row shows Saving… then Saved ✓, and on a server rejection shows Save failed and puts the row back the way the server still has it.
Permissions only where there is an account to hold them
Someone with no sign-in gets an honest explanation and an Invite to log in button instead of 32 permission checkboxes that would write nowhere.
Disable or remove a team member
Disable someone to keep their record but cut their access, or remove them permanently behind a confirm step.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →