Partial-Update Data-Loss Protection Automation: When Saving Four Fields Used to Erase Twenty

A function that assembles a complete database record from a client object is the natural, obvious way to handle a form that genuinely edits every field on that record — and it works perfectly for exactly that case. The danger appears the instant a second, narrower screen reuses that same function to save only a handful of fields it actually cares about: if the function's own logic can't tell the difference between "this field is genuinely empty" and "this field was never mentioned," it has no way to leave anything alone. It either saves everything correctly, or it silently overwrites everything else with a default — and which one happens depends entirely on whether the caller happened to populate every field, not on what the caller actually intended.

Building an entire row from a client object and writing all of it works fine as long as every caller of that function genuinely means to set every field — which is true for a comprehensive edit form and false for almost anything else. In JavaScript, a field a caller never touched shows up as `undefined`, and `undefined` disappears entirely when the resulting object is serialized to JSON — but a NESTED object built by unconditionally reading several `undefined` source fields into it doesn't disappear at all; it becomes a real, populated (if empty-valued) object, and that object reaches the database as a genuine value to write, overwriting whatever was there before. A function correct for a full-record save becomes actively destructive the moment anything narrower calls it, and nothing about calling it looks obviously wrong at the call site — the bug lives entirely inside the shared function's own assumption about what "no value provided" should mean.

The defect surfaced through a systematic audit of all 13 screens under Run's infrastructure settings — described in the audit's own summary as looking for problems worse than the classic empty-shell pattern (fake data, decorative buttons that do nothing), and finding exactly that: real, working screens with defects that were actively harmful rather than merely incomplete. The most severe of them: a "Save data" button on two specific screens (an org-level strategic overview and a deal-intelligence panel) each save exactly 4 numeric and categorical fields relevant to their own purpose. Neither screen touches a client's contact details, address, social handles, or brand assets at all — but both routed their save through the same shared update function used everywhere else in the client-management area, and that function's existing behavior was to reconstruct the ENTIRE client record from whatever was passed in, filling in defaults for anything missing.

Measured directly against the organization's real client data: 22 of 23 active clients had a populated contact-information field. Because the shared function unconditionally rebuilt that field (along with social accounts and address) from source fields that these two specific screens never populate, every single click of "Save data" on either screen was silently erasing contact info, address, social handles, logos, brand colors and the client's legal name for whichever client was open at the time — regardless of how carefully the person clicking save had filled in the 4 fields the screen actually shows. Notably, the file's own pre-existing code already carried a comment warning about exactly this danger, attached to a different, narrower function — the warning existed in the codebase, but the generic path everything else actually used remained exposed.

The fix replaces that generic path, for updates specifically, with a function that checks — field by field, using a direct existence check rather than inferring intent from a value — whether each source field was actually present in the update request, and includes the corresponding database column only when it was. For the nested groups (contact info, social accounts, address), the same discipline applies at the group level: the group is only reconstructed, and only sent, when at least one of its own component fields was actually present in the request; when none were, the entire group is omitted from the update, leaving whatever the database already holds untouched. The one documented exception, called out directly in the fix's own comment: a caller that intentionally edits only ONE field within a nested group (say, only email inside contact info) will still overwrite that group's sibling fields, which is precisely why the single existing caller that legitimately edits those blocks — the full client-editing form — is confirmed to continue sending the complete object for any group it touches, exactly as it always has.

Someone opens the deal-intelligence panel for an existing client and changes only the expected-complexity field before saving. Before the fix, that single field change would have silently rewritten the client's entire contact block, address and brand assets back to blank defaults the moment the save request reached the database — even though none of those fields were ever shown on that screen. After the fix, the update touches only the one column that actually changed, and everything else on the client's record remains exactly as it was.

A narrow, purpose-built save screen can no longer silently destroy data it was never designed to touch in the first place — the blast radius of a save is now limited to the fields that screen actually edits, matching what anyone using it would reasonably expect. And because the fix is a shared function used by the update path generically, any future screen built the same way inherits the same protection automatically, rather than needing its own bespoke fix the next time a narrow screen is added.

A team hoping to intentionally clear a single field within a nested group (say, removing only a client's phone number while leaving email and WhatsApp untouched) will find that the current design doesn't support that as a narrow, single-field operation — editing any field within contact info, social accounts or address still goes through the full client-editing form, which sends the complete group. This fix specifically closes an unintended, silent overwrite; it isn't a general-purpose partial-field-clearing feature for nested data.

A save function that rebuilds a record entirely from a client object treats "undefined" and "explicitly empty" as if they carry no distinction worth preserving — reasonable for a full-record save, silently destructive for anything narrower that reuses it. Centriu Run's fix draws that distinction explicitly: a field is only ever written when it was actually present in the request, so a screen that only ever meant to touch 4 fields can no longer accidentally rewrite the other twenty just by existing.