Recovery

The Recovery page is Zellbox's safety net for destructive actions on events. Every time something is about to remove or cancel an event from the workspace's calendar mirror, Zellbox snapshots the full row first into a separate backup table. You have 90 days to restore any of them individually.

It covers five paths:

Source action	What you see if it goes wrong	Recoverable?
Approve cancellations on a held sync branch	Every event the safety guard refused gets soft-cancelled in one batch	Yes
Sync cancellation (normal, low-volume)	An event Google reported as cancelled disappears from the live grid	Yes
Cancel event (operator click)	The event flips to status: cancelled with a reason	Yes
Delete event (operator click, hard delete)	The event row is removed from the mirror entirely	Yes
Reset calendar data	Every event row, reminder, and tracked-calendar selection is wiped in one shot	Yes — this is the single biggest reason the feature exists

Restoring brings the event back into Zellbox as a fresh row. It is not re-pushed to Google Calendar automatically — that's a separate decision with invite-email implications.

Where to find it

Sidebar → Setup & Help → Recovery (or open /recovery directly). Admin and privileged tiers see the same view; members see only their own backups.

What you see

A reverse-chronological list of every event Zellbox has snapshotted in the selected window. Default filter is "Last 30 days, all reasons", which covers everything inside the 90-day TTL that's actually likely to need attention.

Each row shows:

• Title (from the snapshot at backup time, not whatever the event might have become afterwards).
• Start time in your workspace time zone.
• Reason chip — Quarantine approved, Sync cancellation, Operator cancelled, Operator deleted, or Reset calendar data.
• Source calendar (the Google calendar id, when known).
• Backed up at — when the snapshot was written.
• Description preview (first two lines).
• Restore button, or a "Restored Mon May 27 12:34" note alongside "Restore again" if you've already restored this snapshot.

Filtering

Two filter knobs:

• Reason dropdown — All reasons (default) or one of the five source actions above. Useful when you know you accidentally approved a quarantine and want to see only those backups.
• Time range chips — Last 24 h / 7 days / 30 days (default) / All. All enumerates everything still inside the 90-day TTL.

Restoring an event

1. Find the row.
2. Click Restore.
3. A confirm dialog spells out what Restore does: re-creates the event in Zellbox with the same time, customer, manager, and reminders; the event is restored as Zellbox-only and is not pushed back to Google.
4. Click Restore to confirm.
5. The new event appears on the calendar grid within a second. The customer-link, assigned-manager, reminder offsets, visit mode, phone number — all preserved from the snapshot.

You can restore the same snapshot multiple times. Each Restore creates a fresh mirror row with its own eventId; the original backup record stays for audit. So if you accidentally restored, edited, then deleted the new copy, you can still restore the backup again to recover.

What's NOT restored

• The Google Calendar event itself. Restore lives entirely in Zellbox's mirror. The original Google event is either tombstoned (Google already considers it cancelled — restoring locally doesn't revive it on Google's side) or fully deleted. If your team needs the event back on Google so they see it through the Google Calendar app, manually re-create it there or use the per-event "Push to Google" affordance when it ships.
• Audit history of the original event. A new eventId means the new mirror row starts with a fresh audit timeline (an audit row is written linking back to the source backup id so a forensic query is still possible).
• Customer notifications already sent. If the original event triggered a "Calendar event cancelled" email at cancel time, restoring doesn't unsend it. The new event behaves like any fresh booking.

The 90-day retention window

Backup rows live for 90 days, then are deleted by DynamoDB's TTL sweep. After that the snapshot is permanently gone. The Recovery page warns you when a row is within the last week of its window so you can decide whether to restore it now or let it lapse.

If you find yourself near the 90-day edge for an important snapshot, the right move is to restore the event now — even if you don't need it yet — and re-cancel/delete it later if needed. Each restore creates a fresh 90-day window for the new mirror row.

How the safety net plugs into other workflows

All four destructive surfaces now mention Recovery in their confirmation dialogs, so you know the safety net is there before you click the destructive button:

• Sync Status → Approve cancellations confirm dialog now ends with the backup note. See Sync status.
• Google Sync → Reset calendar data confirm dialog ends with the backup note. See Reset.
• Cancel event and Delete event modals on the calendar end with the backup note. See Calendar.
• The held-events drill-down on Sync Status lists every event the guard refused, so you can preview what will be backed up + then cancelled before clicking Approve.

Forensic trail

Beside Recovery, every destructive action also writes an audit row to BWS_ZELLBOX_CALENDAR_EVENT_AUDIT_LOG (1-year TTL). The audit log answers "what happened to event X" months after the fact; Recovery answers "restore this event now". They're complementary — Recovery is for the operator, the audit log is for the post-mortem.