← All help articles

Undoing changes and recovering deleted things

troubleshootingrun-of-showevents
Undoing changes and recovering deleted things

"I deleted the wrong thing, can I get it back?" is one of the questions every SaaS support inbox gets, and the honest 1pm answer is: usually yes if you act fast, but the recovery path depends on what you deleted. There is no general-purpose recycle bin in 1pm today. Some deletes are reversible, some are recoverable through the change history, and a few are genuinely permanent.

This article maps each kind, what to try, and how to protect against the painful ones.

The thirty-second version

  • Deleted an event by accident: it's gone. Events are hard-deleted, including their files. Restore is not available from the UI. Email [email protected] immediately and we can sometimes restore from a database point-in-time backup if you're quick.
  • Deleted a timeline item by accident: also a hard delete from the timeline. The change history still records what was there, so you can re-create the item from what the history shows (the data isn't gone, just the live row).
  • Deleted a contact by accident: contacts removed from the address book are removed for good. Past events the contact was on retain a snapshot of their name and email; they're not erased from history, just from the picklist for future events.
  • Deleted a file from an event: the file is removed from the event and from blob storage. No restore from the UI. Same as event delete: email [email protected] immediately.
  • Edited a cell to the wrong value: not technically a "delete", but a common version of the same problem. The change history records the old and new values, so you can read the old value off the history panel and re-type it in.

Timeline item history (the closest thing to undo)

Every edit to every timeline item is recorded. The history captures:

  • The field that changed (title, start time, duration, Where, Details, Responsible, etc.).
  • The previous value.
  • The new value.
  • The planner (or crew member, for vendor-side actions) who made the change.
  • The timestamp.

Open the Actions menu on any row and pick History to see this. The list reads chronologically newest-first, so the most recent change is at the top.

The history is read-only. It is not a rollback. You cannot click "revert" and have the system put the cell back. But you can read what was there before, and re-type it into the cell. For most accidental-edit cases, this is enough.

History rows are retained for six months. After that they're pruned in the background. This is long enough for a post-event review or for catching mistakes weeks later, short enough that storage stays bounded.

Recovering a deleted timeline item

Timeline item deletes are hard deletes: the live row is removed from the timeline. But the history is still there.

Open the History panel for the event. Look for an entry that records the deletion: it will show the previous values (title, start, duration, etc.) and a "deleted" action.

Re-create the item from those values. New row, retype the title, set the start time, set the duration, set the Where, paste the Details. The new row is a new row (new ID, new history), but functionally it's the same item.

If the original item had files attached, those files are gone with the item. The blob-storage cleanup runs synchronously on delete. See the file recovery section below.

If the original item had crew assignments, the assignments are gone with the item. Re-assign on the new row.

A few minutes' work is the cost of an accidental delete. Plan around the inconvenience rather than around the irrecoverability.

Recovering a deleted event

Event delete is the most consequential delete in 1pm. It hard-deletes the event row, the timeline items, the share links, the requests, the uploads, and every file in blob storage tied to the event. The cleanup runs as a single transaction; there's no "soft delete" with a timer that you could intervene during.

The UI does not offer a restore button. There is no recycle bin. Once you click Delete on an event and confirm, the in-app data is gone within seconds.

However: Azure SQL keeps point-in-time backups on a rolling 7-35-day window depending on the tier. If you email [email protected] within hours of an accidental event deletion, we can sometimes restore from a backup, but this is a manual operation involving a side-database, and it depends on how recently the backup was taken relative to the event you created. The closer the event creation to the deletion, the more likely the backup misses it entirely.

In practice:

If the event existed for at least a few hours before deletion, restore is usually possible within a 7-day window.

If the event was created and deleted on the same day, restore may not be possible because no backup captured the event in the first place.

Files in blob storage are not on the same backup schedule. Even if we restore the database rows, the files may be gone permanently.

Email [email protected] within minutes if you spot the mistake, not days. Quick action makes restore feasible; delayed action makes it impossible.

Recovering a deleted file or upload

Files uploaded to an event (the Files section, request uploads, RSVP uploads) are removed from blob storage when:

  • The event is deleted.
  • The timeline item the file was attached to is deleted.
  • You explicitly remove the file via the Files panel or the request review.
  • The crew member who uploaded re-uploads a replacement (the previous version is overwritten).

There is no version history on files. Once a file is removed from blob storage, it's gone from our side. If you have a copy locally or in the original email it was sent from, re-upload. If not, ask the original uploader to re-send.

For accidental deletes spotted within hours, email [email protected]. Blob storage soft-delete is enabled on the upload container with a short retention, so very-recent files can sometimes be recovered. Don't rely on it as a workflow.

Recovering a deleted contact

Contacts deleted from the address book are removed from the picklist for future events. They're not strictly purged (past events the contact was assigned to retain a snapshot of their name and email on the timeline-item history, so you don't lose the audit trail of who was on what event). But the contact won't appear as a suggested option when assigning new items, and you can't re-link them by clicking "restore".

If you deleted a contact you still need, the workaround is to add them again as a new contact. The new record has a new ID; their previous events still show the old name. The two are not connected in the database, but for working purposes (sending share links, assigning items) the new contact behaves identically.

If you genuinely need the old contact restored (e.g. to keep historical assignment links intact for reporting), email [email protected]. The same point-in-time restore considerations apply.

"I just made a mess of an event and want to start over"

If you've spent an hour building a timeline and decide it's wrong, you have two clean paths:

  • Path A: edit your way to the right shape. Delete the wrong items one by one, re-create the right ones. Slower, but preserves the event's identity, its share links, and its history.
  • Path B: save the messy event as a template (Save as template in the planner header), then create a fresh event and insert the template. Edit the template's structure on the new event without affecting the original. The original messy event stays as a fallback you can go back to if you change your mind, or delete once you're sure the new one is good.

Path B is the recommended pattern when you're not certain. Templates are cheap and you can have as many as you like. The original event is a safety net.

Practical hedges

A few habits that save grief:

  • Save as template after a finished event. If you ever accidentally delete the original, you still have the template with the same shape. This is cheap insurance.
  • Export your account data periodically. The Export feature produces a ZIP of JSON files covering your events, items, contacts, branding, and requests. It doesn't include the uploaded files themselves (only their metadata), but it does include enough text data to reconstruct the bones of an event from scratch. See Exporting your account data.
  • Use the Status field rather than Delete when you're not sure. Setting an event to Cancelled keeps everything intact and removes it from the live dashboard without losing data. You can change your mind and move it back to Confirmed at any time. Delete is for "I'm sure this should be gone forever".
  • Read the confirmation dialog. Deleting an event pops a confirmation ("Delete this event and all its timeline items?") with the OK button tinted red. Delete also lives at the bottom of the event's edit form, so it takes a deliberate open-edit, click-Delete, confirm sequence rather than a single stray click. The friction is deliberate. If you find yourself clicking through it without reading, slow down: that's the moment the mistake happens.

What's not on the roadmap

A proper recycle bin with restore is something we'd want to ship eventually, but it's not near-term. The current posture (hard deletes with backup-restore as escape hatch) is good enough for the volume of deletes we see in support, and adding a "trash" state introduces its own complications (what about cascading deletes on the timeline items? what about share links? how long does trash last?). When we do build this, it'll be designed properly rather than retrofitted.

Until then, the rules are:

  • Be deliberate about deletes.
  • Email [email protected] fast when something goes wrong.
  • Keep templates around as informal backups.
  • A real person reads the support inbox and we'll do what we can.