← Help centre

Putting an agency back to an earlier time (Admin > Restore)

Signed in? Ask Lovelio this question inside the app - it answers from this same page.

Admin > Restore turns back the clock for ONE agency without touching anyone else. Every change to an agency's records (a candidate deleted, a job edited, a placement added) is kept for 30 days. A restore replays those changes backwards, newest first, until the agency looks the way it did at the minute you chose.

The three screens

  1. Which agency, what time. Search the agency by name. Pick the day and the minute. As soon as you pick, the page tells you in plain words what has changed since then: how many changes, across which kinds of record, by whom. If you only want one candidate or one job put back, narrow it there; only that record and the things hanging off it (applications, notes, documents, interviews) are touched.
  2. Check the plan. A numbered list of what will happen: "3 candidates come back", "1 job goes back to how it looked", "1 placement added since is removed". Nothing has changed yet. The one button says "Put <agency> back to <time>".
  3. The receipt. What was done, how long it took, and one button: "Undo this restore". A restore writes its own history, so undoing it is the same replay run once more.

What happens while it runs

The agency is frozen for the seconds the restore takes. Nothing else can write to it in that window, through any door:

  • People signed in see a short "Back in a moment" page. It tries the app again on its own every few seconds and lets them straight back in when the restore is done.
  • The API and MCP answer 423 with the code RESTORE_IN_PROGRESS, a Retry-After of 60 seconds, and the words "This agency is being put back to an earlier time. Try again in a minute." Nothing was written; the same request sent again after the wait works.
  • Slack, WhatsApp and Ask Lovelio say the same sentence instead of acting.
  • Background jobs (CV parsing, matching, scheduled emails, calendar and mailbox syncs, sweeps) wait and come back after the freeze with their finished steps kept. A job already running when the freeze started is stopped at its next write and comes back too.
  • Webhooks and public forms (application forms, inbound email, Slack events) are refused by the database itself, so the sender gets an error and retries.

The database is the last line: it refuses any write into a frozen agency that is not the restore, whether or not the door checked first. The freeze lifts itself when the restore finishes, and a daily check lifts any freeze left behind if something crashed.

Other agencies are never frozen and never changed. An account that an admin has suspended is a different thing: its data stays writable, its people are kept out, and its background jobs are skipped, not retried.

Limits

  • 30 days. Older changes are gone from history. For anything older, the break-glass path is a database clone (docs/runbooks/agency-restore-from-clone.md).
  • Files. A restored record that points at a CV, document or recording gets its file back too: from the trash if it was deleted in the last 30 days, or from the hourly off-site copy. The receipt says how many files came back and how many could not be found.
  • Imports. Migration Magic loads skip history on purpose: there is nothing to restore an import "back to". Undo an import from the Migration Magic page instead.
  • Usage counters and logs (AI spend, email sends, rate limits) are never rewound.
  • A blocked restore means a record could not come back because something it depends on is missing from history. The receipt says which table. Nothing is half-done: a blocked restore changes nothing.

Undo

Every real restore can be undone once from its receipt, or later from the list of recent restores at the bottom of the page. An undone restore cannot be undone again; run a fresh restore instead.