A confirmation dialog on both drag-and-drop and the card's move control, followed by a lifecycle row carrying the user, their role, the assigned rep, the from and to stages, whether it moved forward or backward, how long the deal sat in the stage it left, the outgoing checklist snapshot and the steps that were on offer.
Also called: who moved this deal · audit trail · stage change history
- 1Both the drag path and the card's move control route through the same confirm and the same persistence
- 2The card is captured before the column mutates, so the audit reflects the stage being left
- 3Dwell time is derived from the moment the deal entered the stage it is leaving
- 4The reason field literally reads 'MANUAL OVERRIDE — stages normally advance from system events'
Stages are meant to advance from real events, so a hand move is an override and the record has to say so — who moved it, their role, which stage it came from, how long it sat there, and that it was manual. Getting this wrong forked deals: one version wrote the deal's own identifier into the field meant for the customer's, which broke the board's duplicate suppression, so the same customer re-appeared as a second card in the old stage on the next rebuild. Every re-drag re-corrupted what a merge had just repaired.
- Stage history with no accountability
- No record of how long a deal sat in a stage
- Drags forking a card into a duplicate
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 →