Undo what you just did. Roll back what somebody else did.
There are two layers here. Anything you personally just did gets an instant ↩ UNDO — no admin, no phone call. Anything big — an import, an apply-to-gigs, a batch retype — saves a full workspace restore point before it runs, whether or not anyone remembered to ask for one. And a restore never runs blind: you see exactly what it would change, gig by gig, before you commit.
The bulk edit you can't take back.
Somebody pastes a booking export in and it quietly overwrites nine gigs that already had gear on them. Somebody selects fourteen unique items and retypes them to bulk, and every serial and service flag goes with them. Somebody deletes the wrong show two days before load-in. None of it is malicious and all of it is Tuesday — the problem is that the moment it lands, the old version stopped existing anywhere.
What's usually on offer instead is a nightly database backup, which is all-or-nothing: restoring last night to fix one botched import also throws away every scan, every crew confirmation and every quantity change made since. So nobody uses it, and the fix becomes three hours of re-typing from memory and a printed pull sheet somebody happened to keep.
With GigPal PRO: the risky action saves a before-state automatically, you can see exactly what putting it back would change, and even the restore itself saves an undo point first — so a bad restore can't leave you worse off than when you started.
Your own undo, and the workspace-wide backup.
Undo your own last move — nobody's permission needed.
Rename a package across 31 items, merge four lines into one bulk entry, edit an item and have it push to every matching unit — each one drops a toast with a plain-English description and an ↩ UNDO. It's offered for 90 seconds, up to five deep if you did several things in a row, and it works for any role — a tech doesn't have to call the owner to unwind their own typo. Undo runs the same save the original action ran, just in reverse, so it gets every safety check that save already has instead of working around them.
It saves a backup automatically. You don't have to ask.
Every action in the app that can change a lot of records at once takes a full copy of what those records looked like first — pushing a setup onto twelve gigs, a CSV import that matches and overwrites existing shows, a batch retype or recategorise, renaming a package, FIX ALL on the data check, asking crew across a whole season. You don't arm it and you can't forget it. You can also name one yourself before you do something you're nervous about, and one is taken nightly for the whole workspace regardless.
Read the damage before you undo the damage.
Open a restore point and it doesn't restore anything — it diffs. The stored copy gets compared line by line against what's live right now: gear lines that would come back, lines that would disappear, quantities that would change, and the actual names of every gig affected. You don't have to trust a button marked Restore — you get the gig names and the line counts first, and you decide.
It refuses when the crew is mid-scan.
Restoring a gig means rewriting what's on it — including who scanned what out to the truck. So before it will run, it checks the gigs inside that particular restore point for live physical activity: gear currently checked out under chain-of-custody, or a pull sheet someone has open right now. Either one stops it cold, and names the gig. The check is scoped to the snapshot's own shows, so unrelated activity on a fourth gig never blocks you — and it runs again in the instant before the write, because a crew member can start scanning while you're still reading the diff.
Undo the undo — and a straight answer about what landed.
Press confirm and the first thing that happens is another snapshot: everything live, right now, saved as "Before restoring …". If that snapshot can't be written, the restore does not run at all — nothing gets touched, and you're asked again, because restoring with no way back out is a different call than the one you just made on the diff screen. Then it writes, gig by gig, through the app's normal save paths. If gig 14 of 30 gets refused, you're told which one and why — never a green checkmark over a half-finished job.
The parts that decide whether you trust it.
Manual · Daily · Auto · Pre-restore
Colour-coded and grouped in the list, because they mean different things. MANUAL is one you named. DAILY is last night's. AUTO is the one a bulk action left behind. PRE-RESTORE is the safety copy a previous restore made of the state it replaced.
Two counters, kept apart on purpose
The newest 20 automatic points are kept by count; nightly ones by age, 30 days. Pre-restore points get their own separate allowance of 10 — sharing one bucket meant a busy show day of routine snapshots could quietly prune away the exact undo-the-undo point you were counting on. A point you named and saved never expires on its own.
A failed snapshot can't block your work
Capture is deliberately best-effort everywhere except one place. If storage hiccups while you're applying a template to twelve gigs, the apply still goes through — a snapshot that blocks the work it's supposed to protect isn't worth having. The one exception is the pre-restore point, where the rule flips: there, refusal is the whole point.
Verified on the server, not in the browser
Everyone in the workspace can see what restore points exist and when they were made — useful on its own. Only the owner can open one, and that's confirmed by the database before a single byte of a payload is handed over, using the same check the storage rules themselves are built on. The UI gate and the real permission can't drift apart.
A snapshot is not a shareable link
The stored copy is a full dump of your inventory, gig contents and rental costs, so it's kept in a private bucket and every read is authenticated against your session. No public URL exists for it — not even an obscure one.
Restores write like a person would
Nothing is force-fed into the database. A restore calls the same save functions the app uses all day, so it inherits their guards for free — including the tripwire that refuses to shorten a rack's contents list unexpectedly, and the rule that aborts rather than delete gear a snapshot still references.
Once per workspace, per day, no duplicates
The scheduled run is idempotent — fire it twice and the second pass is a no-op, not a second copy. Each workspace is handled independently, so one failure never stops the rest, and the run reports exactly which succeeded, which were already done and which failed.
Four different problems, four different sentences
Telling you the inventory didn't restore, when actually it was just the rack contents that got left out, is worse than telling you nothing at all — so failed gigs, failed inventory, failed rack rosters and failed cases are tracked separately and reported separately, by name.
- A restore point holds
- Your whole inventory, every gig with its gear lines, quantities and case assignments, and every road case with its standard contents — plus who saved it, when, its size, and a scope badge: ORG, n GIGS, n ITEMS or n CASES.
- Kept for
- Newest 20 automatic · newest 10 pre-restore · 30 days of nightly · named points kept indefinitely.
- Fires automatically before
- Apply-to-gigs (add, match or remove), CSV import over matched gigs, bulk gig recategorise, batch retype, batch category, merge-to-bulk, package rename and removal, an edit pushed to matching units, FIX ALL package gaps, data-check repairs, and staffing a whole season.
- Refuses to restore when
- Gear on those gigs is checked out under chain-of-custody, a pull sheet is open on them, an audit is running on your device — or its own undo point couldn't be saved.
- Personal undo
- Last 5 actions, 90-second window, any role, no owner involved. Held in the tab you're working in — a page refresh clears the offers, because this catches what you just did, not what you did an hour ago. Deleting a gig or case gets its own 9-second banner; removing gear inside a gig gets an 8-second one that also puts back the case assignment, the rent-list asks and the setup credits it took with it.
- What it is not
- Not whole-database disaster recovery — that's a different layer. This is a record of what your workspace looked like before your last risky change, kept at the level of detail you'd actually want to put back.
A bad afternoon stops being a bad quarter.
Try breaking something.
Bring your inventory in, run a batch edit on it, and put it back — the restore point will already be waiting for you.
Get Started → All features →