All checkpoint saves — Gantt, crew portal, customer-facing sync — route through one server function that upserts the state, re-runs the project pipeline rules, and decides whether the customer is told. Cross-tenant guards refuse a write against another builder's project.
Also called: office and crew ticking the same box · consistent checkpoint behaviour
- 1saveMilestones takes an ACTOR (org, user, name) rather than reading the session, because the two callers authenticate differently — the route proves a Clerk role, the crew portal proves a capability token
- 2It snapshots the pre-save state so customer emails fire on genuine transitions only, not on every re-save of the same map
- 3Two tenancy guards: refuse when an existing row belongs to another org, and refuse when the project registry says the project belongs elsewhere
- 4It then fires the PM pipeline rules and the catalogued customer messages
Ticking a checkpoint is not just saving a checkbox — it decides whether the stage is finished, whether the job advances, and whether the customer gets told. A second copy of that logic anywhere would have been a second answer to 'did the customer hear about this', which surfaces as a customer congratulated twice or never. Every tick, from the office, a phone or the crew portal, goes through one path. That path also checks the job belongs to the company ticking it, after testing showed a signed-in user at any company could submit another builder's job and overwrite their records.
- Two implementations disagreeing about what a tick means
- Cross-tenant data corruption through a guessable id
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 →