Which copy the customer actually gets

An explicit pin always wins; otherwise the fresher of the two copies wins — freshness is compared, never assumed.

What it is

The resolver behind every customer portal load. It chooses between the newest customer-visible sent version and the link's own refreshed snapshot. A deliberate pin beats both. With no customer-visible send version at all, the link's snapshot is used. It never throws — on any error it returns the fallback so the portal always renders something.

Also called: portal showing an old version · wrong quote on their page · version vs link snapshot

See it
Which copy the customer actually gets
Prepared for
Sutter Kline
1140 Ridge Line Rd · Fair Play
Shell package$28,080
Concrete & site$8,152
Doors & windows$5,435
Trim & finish$3,623
Total
$45,290
Signature
Decision diagram: pin → fresher-of-two → link snapshot, with the timestamps that drive the comparison labelled (estimateVersionsServer.ts resolvePortalSnapshot). Sample data — no customer information appears here.
How it works
  1. 1Load the customer-visible send versions for this estimate, newest first.
  2. 2If a selection row points at one of them, that is a pin and it wins outright.
  3. 3A selection pointing at anything else is leftover state, not a choice, and is ignored.
  4. 4Otherwise compare the newest version's timestamp with the link's snapshot_refreshed_at and take the newer.
  5. 5Every query is scoped to the link's own organization.
Why we built it

The same $11,568 of services went missing on a customer portal for a second reason: the customer's copy had been refreshed correctly, but it was losing to an older sent version that outranked it simply by being a version. The rule had been newest version, otherwise the link, which quietly assumed a version is always at least as fresh as the link. An explicit pin now wins, and otherwise the genuinely fresher of the two wins, with freshness compared rather than assumed. Freshness needed its own timestamp because the obvious one moves whenever a customer opens their portal — comparing against that would have made the link permanently newer than every version the first time anyone looked at their estimate. A reader must never change which document is authoritative.

The problem
  • A stale sent version outranking a freshly refreshed customer document
  • A customer merely opening their page changing which document is authoritative
Sound familiar?
What you get
The buyer reads the newest copy unless you deliberately pinned an older one
Version history is untouched — nothing is rewritten to make freshness work
The portal always renders, even on an error

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 →