Review queue decisions and flags
Decisions
Each staged variant in the review queue carries one.
| Decision | What committing it does |
|---|---|
| Pending | Nothing yet. Where every row starts |
| Create | Makes a new Yessort product and variant, links it, and seeds its stock from what was staged |
| Link to existing | Links the listing to a variant you already have. Stock is left alone |
| Skip | Nothing is created and nothing is linked |
Who decided
| Set by | Meaning |
|---|---|
| Automatic | Yessort's own proposal, or nobody has decided yet. Yessort may revise it |
| Operator | A person chose it. Never revised automatically |
Yessort keeps its own proposals fresh as the store changes, but a decision a person made is left alone. Without that distinction, a row you dismissed would return the next time the product was edited in the store, and re-syncing a catalogue would discard the channel's review work.
Checks that flag a row
Run over what was pulled, before you review it.
| Flag | Why it needs a decision |
|---|---|
| Duplicate SKU within the store | The store permits two variants to share a SKU; Yessort does not |
| SKU matches a variant you have | Probably the same product. Link it rather than creating a second |
| No SKU | Yessort matches stock and orders by SKU, so one has to be set |
| Barcode matches a registered physical product | Possibly the same physical item as an existing anchor |
Why a link was removed
Recorded when a listing comes off sale, and it decides what can be restored.
| Reason | Restored when the product goes active again in the store |
|---|---|
| You archived the product | Yes |
| The store archived the product | Yes |
| A single variant was unlisted | No |
Both archive reasons are kept apart rather than recorded as one, so "what has the merchant withdrawn?" stays answerable — it is not, if products you archived and products they archived look identical.
A variant you deliberately unlisted is never restored by a whole-product relink: the merchant reactivating a product says nothing about one variant you chose to stop selling. See unlisting and relisting.
Conflicts
Separate from decisions. Raised when the store sends an edit carrying a SKU or barcode that already belongs to a different Yessort variant.
| State | Meaning |
|---|---|
| Open | Awaiting resolution. The incoming value was not written |
| Resolved | Dealt with |
| Dismissed | Closed without action |
The incoming write is skipped, not queued. There is deliberately no option to apply it anyway — identifiers are how Yessort matches stock and orders, so moving one off the variant that holds it would break matching elsewhere. Repeated events refresh the open record rather than stacking duplicates.