The field is almost certainly owned by another system. When a record is linked to a connected platform that owns that field, the sync restores its value on the next run and the edit disappears. That is the integration working as designed. The fix is a written ownership rule for the field, plus an editing restriction in the system that does not own it.

A field mapping worksheet gives every synced field its own row and records what a developer needs to build it: the source object and field, the HubSpot object and internal property name, the sync direction, the control type, the matching key, the field type and allowed values, the trigger, and the status. Make control type a required column. A rule written only in the brief tends to stay there, and the developer ends up guessing one field at a time.

The integration cannot find the existing record, so it creates a new one. That happens when matching runs on an email address someone has changed, or on a name that exists twice. Store each system’s record ID on the matching record in the other system, then search in a set order: shared record ID first, a secondary key like an account number second, email only when neither ID exists. If several records match, update nothing and flag it for review.

Yes, when the integration is built without a rule against it. An empty incoming value should leave the existing value in place unless the mapping explicitly says to clear it, since a blank usually signals an export gap. That rule belongs in every integration brief, alongside no silent overwrites, no sync loops, matching formats, and writing only the fields the integration owns.