The walkthrough
68.9 seconds. Captions are burned in; an
.srt and .vtt sit beside the file.
The friction, as reported
“Auto saving will send the invoice info through to Trello before the invoice is complete, meaning not all the info will be sent to Trello.”
Verbatim from the Xero Product Ideas board. Reproduced as a contiguous extract and checked against the harvested record.
What the walkthrough shows
- A webhook has already fired three times on a part built invoice.
- The idea asks for one setting.
- Drafts now stay in this browser until Save is pressed.
- Saved has become Unsaved changes. That indicator changed job.
- Save and close now carries every one of those lines.
- Forty lines, none of them written to Xero.
- This confirmation only exists because autosave is off.
- The draft is missing from the org list, so no colleague sees it.
- An explicit save step implies no autosave.
- Autosave implies that save step is decoration.
The assessment
The constraint.
An explicit Save button and continuous autosave cannot both govern the document.
One of them is already in development, and it is not this one.
The reasoning
Two reasons, and the first is the more interesting one.
It collides head-on with work already committed to. Moving the Save button to the bottom of the invoice is In development with 247 votes. An explicit Save button and continuous autosave are not complementary — a Save button in an autosaving editor is decorative, because the document is already saved before you press it. Ship both without deciding which governs and you get the worst outcome available: a control that looks like the fix people asked for and changes nothing.
Switching autosave off has an ordinary, everyday cost. Losing forty line items to a closed tab is not hypothetical; it is what autosave was introduced to prevent. An organisation-level toggle means one person's preference decides whether everyone else's work survives a browser crash.
There is a real reshape available and it loses on scope. The submitter needs event-timing control — fire the webhook on approve, not on draft save — rather than persistence control. That is a developer-platform change with almost no presence on this screen, and it would serve one submitter while ignoring what the other votes are about. The insight belongs in the narration, not the mockup.