Bulk-update existing values

Correcting data you imported before, or re-syncing from a source of truth that's changed. The mechanics are simple; the care is all in reading the check first, because an update overwrites and can't be undone.

Update destroys the previous value

ImportKit doesn't keep what was there before and can't put it back. The pre-import check is your only preview — for metafield values it shows the value currently in your store next to each row, so you can see exactly what you're replacing. Read it.

What can be bulk-updated

Type	What Update changes
Metafield values	The value itself. The most common bulk update by far.
Metaobject entries	The fields you mapped, matched by handle. Fields absent from your file are untouched.
Metafield definitions	Name, description, pin, access and validations. Never the type.
Metaobject definitions	Adds new fields only. Existing fields are never rewritten.
Blog articles	Not supported — a second import creates new articles rather than updating.

Walkthrough: correcting a value on 400 products

Say custom.care_guide was imported with the wrong wording and you have a corrected sheet.

Build a file with only the rows that change

There's no benefit to including rows whose value is already correct — they'd just be charged as updates for no change. Filter your sheet down to the rows that actually differ.
care-guide-fixes.csv
```
owner_type,owner_reference,namespace,key,value
PRODUCT,merino-crew-neck,custom,care_guide,"Machine wash at 30°C. Dry flat."
PRODUCT,linen-shirt,custom,care_guide,"Machine wash at 40°C. Warm iron."
```
Identity is owner_type + owner_reference + namespace + key, so those four columns have to match the existing values exactly for ImportKit to recognise them.
Upload and map as usual

Nothing different here. Metafield values, no target needed.
Run the check in Skip mode first

Counter-intuitive, but this is the useful move. In Skip mode the check reports every row as a skip and shows the current value. That tells you two things at once:
- every row matched something — if any report as create, your reference or key is wrong and you'd be making new values rather than updating;
- what the existing values actually are, so you can confirm you're replacing what you think you are.
All of this is free.
Switch to Update and re-check

Change the conflict mode to Update it with this row's values and press Re-check. The skips become updates and the credit total becomes the row count. Confirm the number matches what you expect to change.
Import

One credit per row. Rows whose owner can't be found still error and are refunded, so a few stale handles don't derail the run.
Spot-check in Shopify

Open two or three products. Then read the job's row results for any warnings — a row can succeed while dropping part of its value, particularly with references.

Screenshot

Check in Update mode, showing what will be overwritten

The check report with rows marked as updates, each showing the existing store value alongside the incoming one, and the credit total at the top.

assets/screenshots/check-update-mode.png

If the check says “create” and you expected “update”

This is the mistake worth catching, and the check catches it for free. It means ImportKit doesn't consider your rows to be the same thing as what's in the store. Usual causes:

Cause	Fix
Namespace mismatch — your file omits it, so it defaults to `custom`, but the existing values are in another namespace	Add the correct `namespace` column
Key typo — `care-guide` versus `care_guide`	Match the existing key exactly
Owner type mismatch — `PRODUCT` where the values are on `PRODUCTVARIANT`	Correct the owner type
Handles have changed since the values were set	Re-export handles from Shopify and rebuild the reference column

Importing anyway wouldn't overwrite anything — it would create a second, differently-keyed metafield. Harder to spot later than a failed import.

What a bulk update can't do

Clear values. Blank cells are skipped rather than written, so you can't empty a field by blanking the cell. Deleting metafields is admin work.
Change a metafield's type. Types are immutable in Shopify. A row with a different type is a conflict in every mode, reported as already exists as "X" but this row says "Y". Create a new definition under a different key and migrate the values.
Rewrite metaobject definition fields. Update adds new fields only.
Update blog articles. No identity, so no updates — only new articles.
Undo itself. There's no rollback anywhere in ImportKit.

For a large or risky update, stage it

Run 10 rows first. Copy the header and ten data rows into their own file, import that, and check the results in Shopify. Ten credits to de-risk a thousand-row run.
Then run the rest. Remove the ten you already did, or leave them in — in Update mode they'd simply be written again with the same values, costing ten credits.
Or rehearse on a development store where charges are test charges, if the data model is complicated enough to warrant it.

Using it as a repeatable sync

Metaobject entries are the best fit for an ongoing sync, because handles are stable identities and Update only touches mapped fields. A workable routine:

Export from your source system, generating the same handles every time.
Import in Update mode.
New records create, changed records update, unchanged records still cost a credit each — so filter to changed rows if volume matters.

Metafield values work the same way, with owner handles as the stable identity.

Duplicates and conflicts

Exactly what Update patches for each import type, and why some things are never touched.

Fix failed rows

For the handles that didn't resolve on the first pass.

Bulk-update existing values

What can be bulk-updated

Walkthrough: correcting a value on 400 products

Build a file with only the rows that change

Upload and map as usual

Run the check in Skip mode first

Switch to Update and re-check

Import