Archiving, History and Never Losing a Record Again

A client calls to dispute an invoice. They swear the agreed rate was lower. You open the tracker, and the rate column says what you thought it said. But did it say that in June? Someone sorted the sheet in August, someone else deleted the “old” rows in September, and the version history is a wall of 400 autosaves labelled with times.

Spreadsheets are a terrible memory. They show you the present and make the past expensive to reconstruct. A proper internal tool can do much better, but only if you design for it.

Deleting is almost always the wrong default

In a spreadsheet, finished rows get deleted because they’re in the way. The sheet gets slow, filters get tedious, and that row from 2023 is just clutter. So someone removes it, and with it goes the evidence for every report, dispute and audit that might need it later.

In your new tool, the default should be: records are never deleted in normal use. They change state instead. A finished project is “Closed”. A departed supplier is “Inactive”. A cancelled order is “Cancelled”, with a reason.

This solves the clutter problem a different way. Your everyday views filter to active records, so nobody has to scroll past history. The history is still there for anyone who goes looking.

Archiving, done properly

“Archived” means a record has stopped being part of day-to-day work but still matters. Three design choices make archiving work:

• A clear archive flag or status. One field, not “move it to the Old tab”. Every main view filters it out by default.
• Read-only once archived. Most changes to an archived record are mistakes. Restrict editing to a small group, and log any un-archiving.
• Links stay intact. An archived customer should still appear on their old invoices. If archiving breaks relationships, people will stop archiving and go back to deleting.

Some platforms offer a built-in archive or “soft delete” (a record that’s hidden but recoverable) as a feature. Others need you to build it with a status field and filtered views. Either is fine as long as everyday users can’t permanently remove records by accident.

When deletion is actually right

There are real reasons to delete: duplicate records created by mistake, test data, and personal data you’re obliged to remove. Keep deletion as a deliberate, restricted action, ideally limited to an admin role. Data Retention: How Long to Keep Records and When to Let Go and Privacy Basics for Ops Teams: Handling Personal Data in Internal Tools cover the “when to let go” side.

Change history: the record’s diary

Archiving keeps the record. Change history keeps what happened to it. In plain terms, a change history (sometimes called an audit log) is an automatic list of every edit: which field, the old value, the new value, who changed it and when.

That’s what answers the invoice dispute. You open the record, look at the rate field’s history, and see that it was changed from 85 to 95 on 14 July by a named account manager. Conversation over, or at least a much shorter conversation.

When you evaluate or configure a tool, check:

• Is field-level history available on your plan, and for how long is it kept? Some platforms keep only 30 or 90 days on cheaper tiers.
• Does it record changes made by automations and integrations, not just people? A surprising amount of data gets changed by machines.
• Can ordinary users see it, or only admins? For most business records, letting the team see history builds trust.
• Can you export it? History locked inside a platform you might leave isn’t much use. Backups, Exports and Exit Plans: Protecting Your Data in Someone Else’s Cloud has more on that.

When built-in history isn’t enough

Field-level history tells you what changed. Sometimes you need a snapshot of what something looked like as a whole at a specific moment. A few patterns help:

• Freeze the important moments as their own records. When a quote is sent, save a copy of the quote as sent, with its line items and price, as a separate record linked to the deal. Later edits to the deal don’t touch it.
• Date-stamp values that change over time. Instead of a single “Price” field on a product, keep a small price-history table: product, price, effective from, effective to. Now “what was the price in June?” is a simple lookup.
• Snapshot your key reports. If leadership reviews a pipeline figure every month, save that month’s figure and the underlying list somewhere fixed. Live dashboards are great, but they can’t tell you what the board saw in March.

A fictional example: a 25-person property management firm kept rent amounts as one field per unit. Every rent review overwrote the old number, so working out back-dated arrears meant digging through emails. Adding a rent-history table, with one row per unit per change, turned a two-day exercise into a filter.

Comments and decisions belong on the record

Much of a record’s history isn’t in its fields at all. It’s in the email where someone agreed an exception, or the chat thread where the deadline moved. When that context lives elsewhere, it’s effectively lost.

Encourage people to leave a short comment on the record when they make a non-obvious change: “Extended to 30 Nov, client delayed sign-off, agreed by Priya.” Many tools support comments on records; if yours doesn’t, a simple “notes log” linked table works. This is cheap, and it’s the part of history people actually read.

Test your memory before you need it

Don’t wait for a dispute or an audit to find out what your tool remembers. Once a quarter, pick a record at random and try to answer three questions:

1. What did this record look like 60 days ago?
2. Who made the last three changes, and why?
3. If this record were deleted today, could we get it back?

If any answer is “not sure”, fix it while it’s a drill rather than an emergency.

Where to start this week

1. Check who in your current tool can permanently delete records, and restrict it to an admin role.
2. Add an “Archived” or “Inactive” state to your main table and filter it out of everyday views.
3. Confirm how long your plan retains change history and whether it captures automation edits.
4. Identify one value that changes over time, such as prices, rates or assignments, and give it its own history table.