Skip to main content
When you change a product property yourself, MerchantOps records that the value came from a person rather than a feed or a machine. That record is what stops the next import from quietly putting the old value back. This page explains how the mark is applied, what it protects against, what it doesn’t, and how to remove it.

​
What gets marked

When you change a product property, MerchantOps compares the new value against the one it replaced. Every property whose value actually changed is marked as a manual edit and stamped with:
  • who made the edit, and
  • when they made it.
Properties you didn’t touch are left exactly as they were — saving a form without changing a field never marks it. Existing marks carry forward when a new version is created, so provenance survives version bumps and the protection doesn’t expire after one import. In the app, a marked property shows a ✋ Manual badge next to it on the product page; hover it to see who edited it and when.
This applies to edits made through the app and through the API alike — anything that writes properties as a person rather than as an import.

​
What the mark protects against

Feed imports. When an import brings in a product that already has manual edits, MerchantOps keeps your value for every marked property, carries the mark forward, and — where the incoming file actually disagreed with your edit — records a conflict on the import job. The conflict names the property, the value the feed carried, and the value that was kept, so a dropped feed value is never silent.
There is one deliberate exception. A JSON import can be run with Overwrite manually-edited fields ticked, for an authoritative resync where the file is the source of truth. That turns the protection off for that run. If you only want to protect specific fields during a resync, leave them out of the file rather than ticking the box.

​
What the mark does not protect against

The manual-edit mark is read by the import path. Enrichment does not read it. Enrichment has its own, separate guard: the per-property overwrite_merchant_input switch, described in How enrichment works. Because a hand edit records the value’s source as your input, that guard is what covers it — and it is off by default, meaning your value stays. The exceptions are the three content fields that ship with overwriting enabled, because they are copy MerchantOps is expected to author:
  • Description
  • Features
  • Meta title
On those three, an enrichment run may replace text you typed, mark or no mark. If you want a hand-written description to survive enrichment, turn overwrite_merchant_input off on that property in the Property Dictionary — see Enrichment configuration and overrides for where the setting lives and how to scope it to one product type or category.

​
Releasing a property back to the feed

When a hand edit has served its purpose — the source system has been corrected, say — clear the mark with Reset to feed next to the property on the product page. An API client can do the same by clearing the manual-edit flag in the property’s metadata. Reset to feed removes the protection on the latest version. It does not change the current value: the value you edited stays until a later import overwrites it.

How enrichment works

Which source wins a field, and the overwrite guard that governs enrichment.

Versioning

How editing creates a new version and which one to trust.

Jobs

Where import conflicts are reported.

Import connectors

How scheduled feeds bring product data in.