Andrews DeanEvery product I've ever worked on wanted the same thing: make it feel alive. Sync it. Refresh it. Show the latest number, the current name, the up-to-date version of everything, always. In one part of a rewards-and-recognition tool I built, I did the opposite on purpose, and it's the decision I'd defend hardest if you pushed back on it.
What a nomination actually remembers
A nomination record carries a handful of facts about the person being nominated: their job level, their role title, which project they're on, which award category they're up for. It looks like one kind of data. It isn't. I ended up giving three different answers to what looks like the same question, because it isn't the same question three times.
The nominee's level and role title get copied onto the record, as plain text, the moment the nomination is created, and then frozen: a snapshot, not a live lookup. The project is different. It's referenced live, by its actual identity, because a project is a stable thing you navigate to, not a label that drifts. And the award category, the free-text value an admin can rename or reorganise, gets resolved to its label text at nomination time and stored as that text, not as a pointer back to the list it came from.
Rename "Senior" and watch what happens
Here's the scenario that made the decision obvious once I actually sat with it. Say an admin renames the level "Senior" to "Senior II" next year, because the company reorganised its levels and the old name doesn't fit anymore. What should a nomination that was submitted, reviewed, and approved last year say, today, when someone pulls up the history?
If the level were looked up live from the employee's current record, the answer is unsettling: the old nomination would silently start saying "Senior II," a title that didn't exist when the decision was made, attached to a decision that was actually about "Senior." Nobody edited that record. Nobody meant to change what it says. It would just quietly start telling a different story than the one that was actually approved, because the thing it was pointing at moved underneath it.
Freezing the level onto the record at creation time means the old nomination keeps saying "Senior," permanently, because that's what was true when someone actually approved it. The tradeoff is real, and I wrote it down instead of discovering it by accident later: a renamed level can now show up as two distinct entries in a historical report going forward, old nominations saying "Senior," new ones saying "Senior II." That's the correct, honest shape of what actually happened, not a defect to apologise for.
The dangerous direction isn't the one you'd guess
Most people's instinct, mine included for a long time, is that stale data is the risk and fresh data is the safety. Old numbers, old labels, out-of-date names: that's the thing you're supposed to be paranoid about, and "make it live" is the fix everyone reaches for by default.
This is the one case where that instinct points the wrong way. The dangerous failure mode here isn't the record that looks a little dated. It's the record that silently reinterprets itself every time someone edits an unrelated dropdown somewhere else in the app, and does it so quietly that nobody notices until a person asks, months later, why an old decision suddenly reads differently than they remember approving it. A frozen record announces its age. A live-lookup record that's been retroactively rewritten doesn't announce anything at all. It just sits there, wrong, looking exactly as confident as it did the day it was correct.
Not every field wants the same answer
The same principle governs what happens when someone tries to delete a level or a project outright, not just rename it. If nothing in the system's history points at it, deleting it is fine. If a decided nomination still references it, hard deletion is refused, and the only option offered is archiving it out of future dropdowns while leaving it exactly where it is for anything that already points at it. The record's right to keep saying what it originally said outranks an admin's convenience in tidying up a list.
I don't think the lesson here is "always freeze data" any more than it's "always keep it live." It's that reference data used inside a historical record is really two different questions wearing one field name, and you have to answer them separately, field by field, on purpose. Is this a stable identity someone navigates to, where you want the current truth? Or is this a label describing what was true at a moment that's already passed, where you want the truth as it stood then? Get that backwards in the live-lookup direction and the mistake is nearly invisible, because nothing breaks. History just quietly stops being history.
Let me say the part that's easy to skip past: the most honest version of a historical record is not the one that's always up to date. It's the one that still says, truthfully, what was true when it mattered.
So look at the fields in your own product that update quietly, automatically, every time someone edits a value somewhere else. Which ones are supposed to move with the present, and which ones are secretly telling you what happened in the past, in the present tense, without you ever asking them to?