One answer to 'who works here'

The team roster is merged from four separate stores into one person per human, so field staff without logins and reps without accounts still appear as themselves.

What it is

A single resolver that reads crew records, sales rep records, the membership mirror and the identity provider, then folds them into one row per person — matching on user id first, then lowercased email, then normalised name. When one human appears in several stores with several roles, the richest role wins because the higher grant is the one with security meaning. Aliases are kept so a link minted under an older id still resolves.

Also called: team list · staff directory · roster · people with no login

See it
One answer to 'who works here'
CustomerBuildingAmountStatus
Gideon Alt30×40 Garage$8,800Open
Ivy Brubaker30×40 Garage$5,000Paid
Ivy Brubaker40×64 Shop$18,110Open
Ronan PetschBarndominium$18,110Open
Ivy BrubakerEquipment Storage$5,570Paid
The team roster showing merged people with source chips (login / member / sales / crew) and a 'no login yet' marker. src/lib/orgRoster.ts feeding the Team page. Sample data — no customer information appears here.
How it works
  1. 1Four sources are read: crew members (field labour, usually no login), sales rep records, the membership mirror, and the identity provider.
  2. 2Identity folds on user id, then email, then normalised name, in that order of trust.
  3. 3Merging keeps the highest-ranked role across sources.
  4. 4Placeholder names — blank, '(no name)', or an email standing in for one — are recognised and not treated as real names.
  5. 5Every id a person has been seen under is kept in an alias list, because the best id moves when a field worker later gets a login.
  6. 6Only names, roles, crew membership and work emails are exposed — no phone, no pay, no rate.
Why we built it

The header states the failure that produced it: 'Reading one and calling it the team is how the Team page ended up with no sales reps on it.' It was extracted from a single endpoint when a second surface needed the same answer and asked one table on its own — 'which meant a framer who exists only in crew_members (the common case for field labour) could be handed a field link that resolved to nobody, and a crew leader's roster came back holding only whoever happened to have a login.' The alias list has its own reason: the best id 'MOVES: the day a framer gets a login, the merge promotes his Clerk id over the crew row's. A field link minted last month carries the old id.' Privacy is bounded explicitly — 'Pay lives on the crew record and stays there, behind its own permission.'

The problem
  • People without logins were invisible to any surface that read the login system.
  • The same human appeared multiple times because each store knew a different slice.
  • Links minted against an older identity stopped resolving when someone gained a login.
Sound familiar?
What you get
Everyone who works for you appears once, whether or not they have a login.
Roles merge upward, so an admin who also leads a crew reads as an admin.
Old field links keep working after someone gets an account.

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 →