On every stage move, manual or automated, the outgoing checklist state is snapshotted onto the lifecycle row along with which steps were on offer at the time, then the live state is cleared for the new stage.
Also called: stage history · what did we actually do in that stage · checklist history
- 1The snapshot is taken BEFORE the reset, so nothing is lost — it moves to the audit log
- 2Which steps were offered resolves through the org's own SOPs first, then the defaults, so a tenant's custom steps render by label rather than as raw keys
- 3The same semantics apply to the automated advance path and the project pipeline handoff, so 'the sales→PM handoff never eats SOP history'
- 4Historical rows recorded before per-visit resets are captioned honestly by resolving which stage a step actually belongs to
Checklist work was not tied to the visit that did it, so when a deal moved on, the snapshot credited every earlier stage's steps to whichever visit happened to close — eight steps done during estimating showed up filed under the first contact. Any report built on that described reps doing work they never did, in stages they were barely in. Each visit's work is snapshotted and reset as the deal leaves the stage, so the record matches what happened.
- Checklist work attributed to the wrong stage
- Losing the record of what was done when the deal moved
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 →