Manual edits

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.

​

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.

​

Enrichment honors the mark too

A manually edited field is also protected from enrichment, permanently — no enrichment run replaces it, including on the three fields below and however the property’s source_priority is ordered. Re-running enrichment fills the gaps around your edit instead of touching it. This is a stronger guarantee than the per-property overwrite_merchant_input switch described in How enrichment works. That switch only covers an ordinary merchant-supplied value — one that came from a feed or import but was never hand-edited — and it is off by default. The exceptions are the three content fields that ship with overwrite_merchant_input enabled, because they are copy MerchantOps is expected to author:

• Description
• Features
• Meta title

On those three, an enrichment run may replace merchant-supplied text — but never text you edited by hand, which the manual-edit mark protects regardless of this switch. If you’d rather feed-supplied copy survive enrichment too, 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.

​

Variant properties are marked too — with a narrower guarantee

Editing a variant property by hand marks it the same way, whether you edit one variant on its detail form or many at once through Mass Update. The badge and the release control are the same, and a marked variant property survives feed imports exactly as a product property does: your value is kept, and the import job records a conflict naming the property, how many variants were affected and a sample of their keys. Conflicts are reported once per property rather than once per variant, so a rename kept across two hundred variants is one line on the job, not two hundred. The same Overwrite manually-edited fields option on a JSON import turns the protection off for that run, for variants as well as products.

​

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.