# What Is Field Overwrite in an Online Store?

> Field overwrite: an app, a PIM or a sync overwriting a product value another system wrote, how it happens and how to catch it.

URL: https://clione.ai/glossary/field-overwrite/
Lang: en

This is not about overwriting a file, or about one CSS rule in the theme overriding another. It is about data: **a product field that somebody wrote and another system wrote over**, without anyone deciding it should be that way. The symptom is familiar in any store with more than one tool connected: you fix a description in the afternoon and the next morning the old one is back, or the title your agency prepared disappears after you install a new app. It matters for a store because lost work gives no warning: the [product page](/glossary/product-page/) is still published, looks fine, and says something else.

## How it works

**The last one to write wins.** An integration that sends the full value of a field and saves it as is, without looking at what was there, cannot know whether someone changed it first. If two systems write the same field that way, the outcome does not depend on which one is right, but on which one synced later. The problem is old enough that the HTTP standard gives it a name: the `If-Match` header is mostly used on requests that change data **to prevent accidental overwrites when several agents act on the same resource at once**, that is, to prevent the "lost update" problem.[^rfc9110] The server applies the change only if the resource is still the one the client read; if someone changed it in between, it refuses.[^rfc9110]

**Platforms solve it halfway, and optionally.** In Shopify, [metafields](/glossary/shopify-metafields/) are written with the `metafieldsSet` mutation, which according to its documentation sets the value whether or not the metafield existed before. Since API version 2024-07 it supports a prior check: if the writer sends the `compareDigest` field, **the mutation saves the value only if the stored one matches the one that was read**; if it does not match, it returns an error instead of overwriting.[^shopify-metafieldsset] It is the right protection, but it is optional: an app that does not send that field writes over it without asking.

**Sometimes the last one wins by design.** Not every overwrite is an error. In [Google Merchant Center](/glossary/google-merchant-center/), an attribute rule called "Take latest" takes, for [price and availability](/glossary/price-and-availability/) only, **the most recently updated value among two or more data sources** and uses it to fill the attribute.[^gmc-attribute-rules] It is a declared overwrite: someone decided that on those two fields the freshest data rules, wherever it comes from. What turns an overwrite into a problem is that nobody decided it.

**Where it usually happens.** There are three typical situations in a store:

- **A source system that exports everything.** A [PIM](/glossary/pim/) or an ERP that sends the full product on every sync puts back its own value on any field that was edited in the store.
- **Two apps on the same field.** Two SEO tools, or an SEO tool and a translation tool, that write the same title or description overwrite each other in whatever order they run.
- **The platform or the theme.** A bulk CSV import, a template that fills an empty field or a theme change that rewrites default values write over what was published.

**The date is not enough to detect it.** The quick way to get suspicious is to compare the product's modified date with your last write. It works as an alarm, but not as proof: in Shopify, a product's `updatedAt` is the date of its last modification and **can change for other reasons**; for example, an order for a product with inventory tracking counts as an update.[^shopify-product] To know whether a field was overwritten, you have to compare the field's value.

## In a store

An ordinary night at a mountain gear store on Shopify, with a PIM that exports every night and an SEO app. It is a **fictional example**: the store, the times and the texts are invented to show how an overwrite chains together.

| Time (fictional example) | Who writes                           | Field                                 | Value stored afterward                           |
| ------------------------ | ------------------------------------ | ------------------------------------- | ------------------------------------------------ |
| Monday, 3:00 a.m.        | The PIM, in its daily export         | Description                           | Manufacturer's text                              |
| Monday, 5:30 p.m.        | The content team, by hand in Shopify | Description                           | Their own text, with sizes and materials         |
| Monday, 5:45 p.m.        | The SEO app                          | [_Meta title_](/glossary/meta-title/) | New title, with the model                        |
| Tuesday, 3:00 a.m.       | The PIM, in its daily export         | Description                           | The manufacturer's text again                    |
| Tuesday, 3:00 a.m.       | Nobody                               | _Meta title_                          | Kept, because the PIM does not export that field |


The fourth row is the overwrite: nobody decided to go back to the manufacturer's text, but the PIM rules that field and nobody told the content team. The fifth is the one that survives, and only because that field is not in the export. The fix is not technical but a matter of who owns what: either the description is edited in the PIM, or the PIM stops exporting it. When the platform or a PIM overwrites a field Clione published, Clione flags it on the next sync with the date and the exact fields, and republishing it is your decision.


That a product's modified date tells you what changed. **A new date does not mean someone touched your field**: in Shopify the last-modified date also changes when, for example, an order adjusts inventory.[^shopify-product] The proof is the value: the one you published, compared with the one there now.


## How to check it

1. **List everything that writes to your catalog**: the platform, the PIM, the ERP, every app with write permission, CSV imports and the people on the team.
2. **Write the field map**: for each field, a single system in charge and the rest only receiving. A field with two systems writing is an overwrite waiting to happen.
3. **Test one field.** Change a value by hand on a test product, wait for each system's next sync and see whether it is still there.
4. **Compare values, not dates.** Save what you published and compare it with what is in the store; the modified date only says that something changed.[^shopify-product]
5. **Ask each integration whether it writes with a prior check**, with `If-Match` on an HTTP API or with `compareDigest` on Shopify metafields, or whether it writes over without looking.[^rfc9110][^shopify-metafieldsset]

## Related concept: data drift

[Data drift](/glossary/data-drift/) is the difference that builds up over time between two places that should say the same thing, like the [product feed](/glossary/product-feed/) and the published product page. Overwrite is a specific event: one write that erases another. Often one leads to the other, because **every overwrite nobody detects leaves two versions of one value**, the one you meant to publish and the one that got published. Drift is found by comparing; overwrite is prevented by deciding who writes each field, and detected by comparing the value right after each sync.

To keep going, the [platform publishing reading path](/learn/publishing-by-platform/) orders the rest of the terms, and the entry on the [PIM](/glossary/pim/) explains how a catalog is divided among systems.