Choose Update-Only or Create-and-Update Imports

Match import modes to authorized changes, quarantine missing IDs, and test expected creates, updates and no-change records before a bulk CRM load.

10/23/20263 min read

A fictional five-row pilot routes one update, one create, one no-change match and two holds.
A fictional five-row pilot routes one update, one create, one no-change match and two holds.

An import meant to refresh existing accounts creates dozens of new records because some matching keys are blank. Another import silently skips genuinely new companies because the operator selected an update-only route. The file may be well formed in both cases. The error lies in choosing an action mode that does not match the intended business change.

Choose the mode before preparing the final file. Define which rows may create records, which may update them, and what should happen when a key is missing or unmatched. Separate files or staged jobs can make those permissions clearer than one mixed batch.

Start with the allowed change

Ask whether the task is a correction of known records, an onboarding of new entities, or a reviewed combination. A correction generally should not gain permission to create records merely because matching fails. An onboarding task should not overwrite existing records simply because a guessed key happens to match.

HubSpot's documentation explains that rows with blank Record IDs can create new records. Verify available modes and matching behavior in your actual importer. Interface labels such as update, upsert, or import may have tool-specific meanings; do not infer safeguards from the word alone.

List the fields allowed to change and the treatment of blanks. Mode selection does not replace field-level protection. An update-only operation can still damage the right record by writing the wrong values.

Use a compact decision tree

Begin with a row's intended action and independently established identity.

  • Known destination record, approved correction, valid matching key: eligible for the supported update-only path.

  • Known destination record but missing or ambiguous key: hold for identity resolution, not creation.

  • Reviewed new entity with no existing match: eligible for an authorized create path.

  • Uncertain whether new or existing: quarantine until matching is resolved.

  • Mixed dataset: split by reviewed action or use a supported mixed mode only when each branch has explicit expectations.

For every branch, record what a missing match should do: reject, hold, or create. The operator should be able to predict that outcome before clicking import.

A fictional five-row pilot

Suppose a team intends to refresh account classifications and add one newly approved company. Its synthetic fixture contains five rows.

R01 has a valid destination ID and an approved new classification. It should update one existing account. R02 has a known company but a blank destination ID. It should remain held. R03 has a key that matches two candidates because of an upstream error. It should not choose either candidate. R04 is the reviewed new company and should create one record through the creation path. R05 contains the same current classification as the destination and should produce no substantive change.

The expected totals are one substantive update, one create, one no-change match, and two holds. A dashboard may categorize no-change rows differently, so retain record-level expectations rather than relying on its summary vocabulary.

Verify that the mode prevents unintended actions

Run the fixture in an isolated area with side effects controlled by an authorized administrator. Inspect new-record counts, matched destination IDs, changed fields, and rejected rows. Confirm that R02 does not create a duplicate and R03 does not overwrite an arbitrary account.

Re-run the same approved file in the test environment. A repeat should have the documented idempotent or no-change behavior for your design, rather than creating another copy of R04. If the source does not receive the newly created destination ID, establish a supported stable-key mapping before scheduling repeated imports.

Check whether dependent automation reacts to matched but unchanged records. Even when the data is stable, a repeated import may still trigger an action under some configurations. Treat that as a separate acceptance criterion.

Save the selected mode, matching fields, create and update permissions, expected outcomes, and test evidence with the mapping. If a future operator wants to switch modes to reduce the rejection count, require review of the changed action scope. A rejected unmatched row is often the safeguard working correctly, not an obstacle to bypass.

If you are also choosing research access, ask about Leads Automation’s independent Sales Navigator offer at US$15/month on WhatsApp. Confirm the available plan, eligibility and terms before ordering; this is not LinkedIn’s official price or an assurance that any particular integration is included.

Sources and scope

Related guides