Record Owner Wrong After Sync: Owner Is a Foreign Key

After a sync or an import, the record owner is wrong in one of three ways: the integration user owns everything, records point at a rep who left last year, or the owner you set on Monday was changed back by Tuesday. All three have the same cause. Owner is not a text field. It is a foreign key into the receiving system's own user directory, and the write only lands on the person you meant if that person exists there under a matching key, is active, holds the seat or security role that system requires for ownership, and the receiver's own assignment machinery does not overrule you after the write succeeds. When any of those fail, most systems do not error. They fall back to the user your API key belongs to, and the run goes green.

Why the integration user owns everything

The symptom operators notice first, usually weeks in: filter the CRM by owner, and one user owns 3,000 records. That user is "Zapier Integration" or "n8n Service Account" or the admin who set up the connection. This is not a connector bug. It is the documented default in every system we checked, and it fires whenever the owner value cannot be used.

HubSpot's documentation on its Salesforce integration states it plainly: when an unassigned HubSpot record syncs to Salesforce and creates a new record, "its Owner will be set to the Salesforce user that created it, i.e. the integration user in the HubSpot account." Zoho CRM's API documentation says that "if you do not specify the owner, the system assigns the current user," and the current user is whoever the token belongs to. Salesforce's knowledge article on the Data Import Wizard says ownership "is set by default to the user performing the import" unless an owner column is mapped, then adds the version that hurts: if multiple users share the same name, records mapped to that name go to the importing user too.

Two paths reach the same state: you never sent an owner, or you sent one the receiver could not resolve. Either way the receiver substituted itself and returned 200, so nothing in your run log tells the two apart.

It matters more than most field mismatches because of what hangs off owner. Round-robin skips records that already have one. Reports roll up by it. Notifications, follow-up tasks, and territory rules key on it. Three thousand records owned by a service account are three thousand records nobody is working, and the dashboard says pipeline is healthy.

What each owner field actually accepts

The owner field looks the same everywhere: a dropdown of people. Underneath, each system wants a different key, runs a different eligibility check, and does a different thing with a bad value. Each row was checked against the vendor's current documentation in September 2026.

System	What the field wants	Who can be the owner	What happens with a bad value
Salesforce (OwnerId)	A User ID, or for leads and cases a Queue ID. The Data Import Wizard also accepts full name or email	An active user with read access. The status code reference defines INACTIVE_OWNER_OR_USER as "the user or record owner isn't active" and TRANSFER_REQUIRES_READ as assignment to a user who "doesn't have read permission." Inactive owners need the Update Records with Inactive Owners permission	API: rejected with one of those codes. Import Wizard: name collisions go to the importing user, and an invalid owner value can fail the whole job
HubSpot (hubspot_owner_id)	The owner id, not the userId. HubSpot's owners documentation says using userId to assign ownership produces errors	A user with a View-only, Core, Sales, or Service seat. Deactivated users keep existing records but are "removed as options when setting the owner of a record"	Rejected as an invalid property value. On the Salesforce integration, an owner with no active Salesforce match makes the Owner ID field "reset to the last value from Salesforce"
Microsoft Dataverse (ownerid)	A systemuser or team GUID	A user with Enabled status and a security role with Read privilege on the table. Microsoft's documentation adds that a Disabled user can still own records "provided the user has Read privilege on the table"	API: rejected. Import wizard: rows whose mapped owner has no security role land on the importing user
Zoho CRM (Owner)	A JSON object with the user's id from the Users API	A user returned by the org's Users API	Omitted: "the system assigns the current user as the owner." Invalid: the row is rejected
Airtable (user field)	Either an id or an email, per the field model	Anyone with workspace, base, or interface access	No documented fallback; the write has to name a user Airtable can resolve. With the notify toggle on, every write sends a notification
Notion (people property)	A user object with id only; email is not accepted on write	A workspace member. The integration sees emails only if its user capability includes email addresses	Rejected. Without the email capability you cannot even build the lookup table

Read the table for the pattern. Every column-two entry is an ID that means nothing outside that system. Every column-three entry is a check on the person, not the value: active, seated, permitted to read. Every column-four entry is one of two outcomes, a rejection you can log or a silent substitution you cannot.

Two rows contradict each other on purpose. Dataverse lets a disabled user own records because its design treats ownership as history. Salesforce refuses by default because its design treats ownership as responsibility. A sync built against one and pointed at the other breaks in the direction you did not test: Dynamics to Salesforce, every record owned by someone who left fails with INACTIVE_OWNER_OR_USER; Salesforce to Dynamics, every departed rep goes through and Dynamics files a thousand records under someone who cannot log in.

The write succeeds and the receiver changes the answer

This is what separates owner from every other field mismatch, and the single-vendor threads miss it because each sees only its own system. A successful owner write is not the end of the transaction. It is an event, and the receiver reacts to it.

Salesforce runs assignment rules on your insert by default. The REST API documentation for the Sforce-Auto-Assign header says it applies when creating or updating Accounts, Cases, or Leads and that "if the header is not provided in the request, the default value is TRUE." Salesforce's knowledge article on ownership changing automatically names assignment rules first: they "automatically reassign record ownership based on criteria you define." So a lead you insert with a carefully resolved OwnerId goes to whatever rule entry matches its state and industry, and the owner your log recorded is not the owner in the record thirty milliseconds later. The header applies to updates too, so a re-sync can reassign a lead a rep has been working for a month. An HTTP node in n8n, Make, or Zapier sends no such header, which means it sends TRUE.

Salesforce also cascades. Its knowledge article on transfers explains that when an account changes owner, related contacts and opportunities owned by the previous account owner move with it, while children with a different owner stay put. An account sync that writes owner rewrites contact and opportunity ownership too, for a subset the sync cannot see.

Dataverse cascades through parental relationships; Microsoft's documentation says an owner update "can have a cascading effect" wherever the relationship behavior is parental. Its Reassign Records tool moves every record a user owns "regardless of state," and the next sentence is the one that catches people: it "also unpublishes any workflows that you assign to another user." A cleanup meant to fix ownership switches off automations that were running fine, a cousin of the credential failures in what breaks when an employee leaves.

HubSpot reacts in two quieter ways. Users get a notification when a contact, company, deal, or ticket is assigned to them, and HubSpot's documentation notes that import is the one path that does not notify, so an API backfill of 3,000 owners is 3,000 notifications and an import of the same file is none. And every owner write sets hubspot_owner_assigneddate, "the most recent timestamp of when an owner was assigned," so any report that measures rep response time from assignment now measures from your sync. Airtable has the same notification exposure through the "Notify users with base access when they're added" toggle on the user field.

Then there is the revert. HubSpot's lead-owner documentation says that after the first sync, changes to either the HubSpot owner or the Salesforce Owner ID sync to the other system, but only owners that "match an active Salesforce user's name and email address" go across, and for an owner with no match, "the Owner ID field will reset to the last value from Salesforce." That is the Tuesday problem from the opening paragraph. A manager reassigns a deal to a new hire who has a HubSpot seat but no Salesforce user yet. The sync fails to resolve the new owner and writes the old one back. From the manager's chair, HubSpot undid their change. From the sync's chair, it did what the documentation says. It is a field-level conflict of the kind covered in two-way syncs that overwrite data, manufactured by a missing user rather than a competing edit.

Build the user map and decide the four outcomes

The fix is a table you own, not a setting you find. Call it the user map. One row per human: email as the join key, then Salesforce User ID, HubSpot owner id, Dataverse systemuser GUID, Zoho user id, Notion user id, and a status column that says active or departed with a date. Resolve email to ID once, when you build the table, and never write an email or a name into an owner field at runtime. Every ambiguity failure in the Salesforce knowledge article, duplicate names, duplicate emails, a leading space in the import file, disappears when the sync writes an ID it already verified.

The map changes on two events, a hire and a departure. Hires get caught because someone asks why their records are missing. Departures rot, because the status column drifts from the systems in silence. The offboarding inventory we recommend for credentials should include the user map, and whoever deactivates a rep flips that row.

Then, before the first record moves, decide what the sync does in each of the four cases it can hit when it resolves a source owner:

Match, active in the receiver. Write the receiver's ID. This is the only case where the write should happen without a second thought.

No match. The receiver has never heard of this person. Write a named fallback owner and log the miss. The fallback is the decision most teams get wrong: it must be a real human or a queue a human watches, never the integration user, because the integration user is where records go to be forgotten. In Salesforce, leads and cases can be owned by a queue, and a queue called "Unmapped from sync" with one person watching it is the right answer. HubSpot has no queues, so use a designated person plus a sync_owner_unresolved checkbox the sync sets and a saved filter on it. Either way the miss shows up where someone looks.

Match, but inactive in the receiver. Do not write the departed user, even where the receiver would accept it. A record owned by someone who cannot log in is a record nobody works. Write the fallback and keep the history in a text field such as previous_owner_email.

Ambiguous match. Two users with the same email or name. This never reaches runtime if the map holds IDs, but it will the day someone bypasses the map and pastes an email. Treat it as no match, write the fallback, and log both candidates.

Two settings finish the job. Send Sforce-Auto-Assign: FALSE on every Salesforce write where the sync has already decided the owner, and TRUE only where you want Salesforce's routing to decide; the choice is per request, and mixing them is fine when it is deliberate. And in any two-way sync, take owner out of the automatic conflict rule. Owner flows one way, from the system where a human assigns work to the systems that display it, and the map decides what "the same person" means on the other side.

Log the resolution, not just the write. The run record from what to log in every automation should carry the source owner key, the resolved receiver ID, and which of the four cases fired. When the sales manager asks why a record is owned by the fallback, that log answers in one lookup instead of an afternoon in the record's history.

What to do next

Run one query in each system the sync writes to: count of records grouped by owner. If the integration user, a deactivated user, or a "Deactivated User (email)" placeholder is in the top five, the sync has been resolving owners by accident. Pull those records into a sheet, build the user map from the email column, and reassign them in one batch, remembering that the batch is itself an owner write and will notify, cascade, and reset assigned dates unless you plan for it.

If the sync is not built yet, build the map and pick the fallback owner before the first record moves. It is the same discipline as the business date field in created dates that come out wrong after import: the receiver's version of the fact is correct from its own point of view, and the sync has to carry yours. We wire this resolution step into every lead routing and CRM handoff we build, because a lead that reaches the CRM owned by a service account was not routed at all. If you have a CRM where one login owns most of the pipeline and are not sure which sync put it there, tell us which two systems are involved at /contact.