Crews.lead_user_id is the single source of truth for leadership when set: exactly that member is lead and everyone else a member. Manual (non-Clerk) members fall back to crew_members.role, and the previous lead is demoted either way.
Also called: made him lead but it didn't save · crew lead · who runs this crew
- 1setCrewLead flips the cache optimistically, then writes lead_user_id for a Clerk-synced member or crew_members.role for a manual one.
- 2Any stale manual lead is demoted so role-based fallbacks agree with the pointer.
- 3loadCrews re-derives every member's role from lead_user_id when it is set.
- 4The change is written to the audit log with the crew, the new lead and the previous lead.
Marking someone a crew leader worked until the next page refresh, when the account sync ran and quietly wiped it — the made him leader but it does not stick complaint. Leadership is stored on the crew itself rather than on the membership record that gets overwritten, so it survives every refresh and every re-sync. Who leads a crew decides who can close a stage and who sees the crew's roster from the field, so it has to be durable to be worth anything.
- Leadership stored in a table that a sync rewrites.
- Crews with no effective leader and therefore no one able to sign or complete stages.
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 →