Resolve the SKU queue

When a SKU sync finds a SKU it can't recognize, it doesn't guess. It puts the SKU in a review queue and waits for a person to classify it. Nothing about that SKU changes in the system until you confirm a decision. This guide walks through that decision.

Where this lives

Open Settings → SKU Sync, then the Queue tab. Every signed-in user can work the queue. For the tables behind it, see SKU Sync in the database reference.

Open the queue

The Queue tab lists each SKU waiting for review. Narrow it down before you start:

Status tabs: Pending, Classified, Dismissed, and All. The queue opens on Pending, which is the work that needs you.
Brand lets you pick an account to see only its SKUs.
Search takes a SKU code or name; press Search to filter, and Clear removes the filter.

Each row shows the ShipHero SKU, its name, the brand, a Suggested type, the current status, and the resolution once it's decided.

What "Suggested" means

The sync tries to classify each SKU by checking ShipHero, and shows its guess as a colored badge:

Base (purple): looks like a single stock unit.
Case (orange): looks like a case that wraps a base unit.
Product (blue): looks like a kit built from other SKUs.
No suggestion (red): the ShipHero check couldn't confirm a type. You'll classify it manually.

The suggestion only pre-selects a default in the review dialog. You always have the final say.

Review one SKU

Click Review on a pending row. The review dialog opens with the SKU's code, name, and brand at the top. If ShipHero marked it as a kit, a Kit badge shows how many components it has.

Nothing happens until you confirm

The dialog only stages a decision. The system creates or links nothing until you click Confirm, and Cancel discards everything.

The dialog defaults the Action to match the suggestion: a product suggestion pre-selects Add as new Product SKU, case pre-selects Add as new Case SKU, and everything else pre-selects Add as new Base SKU. Change it to any of the actions below.

Choose an action

There are five actions, in two families: create and dismiss.

Create a new SKU

Action	What it does	What you provide
Add as new Base SKU	Creates a new Base SKU and inventory records in every warehouse linked to the brand.	Nothing else.
Add as new Case SKU	Creates a new Case SKU linked to an existing Base SKU.	The Base SKU it wraps, and the base-unit quantity per case.
Add as new Product SKU	Creates a new Product SKU (a kit) with junction links to existing Base SKUs.	One row per component, each mapped to a Base SKU with a bundle count.
Create as both a base AND product SKU	Creates this SKU as both a new Base SKU and a new Product SKU, linked through the junction (a "lone-wolf" SKU that is sold on its own).	The base-unit quantity per product.

Dismiss

Dismiss marks a SKU that should not exist in the system. Nothing is created or linked. The entry moves to the Dismissed status and drops out of the pending work.

Classify a kit (new Product SKU)

Kits need the most care, so they get their own panel. When you choose Add as new Product SKU, the dialog lists one row per component ShipHero reported.

Every component must resolve to a Base SKU

A Product SKU is only as real as its parts. Each component row has to map to an existing Base SKU before you can confirm. If a Base SKU is missing, close the dialog, classify that Base SKU from the queue first, then come back to the kit.

The app helps you:

For each component it searches the brand's Base SKUs and auto-matches any whose code matches the component exactly. A green check marks a matched row.
A red No matching Base SKU found warning marks a row you must resolve by hand. Use its search box to pick the right Base SKU.
Add component adds a row; the trash icon removes one.
Each row carries a bundle count: how many base units the kit uses of that component.

You can't confirm while any component is still unresolved.

Confirm

Click Confirm. The app validates your inputs first. For example, a case needs a linked Base SKU and a quantity above zero, and a product needs every component resolved. If something's missing, it tells you and keeps the dialog open.

On success the app calls the resolve endpoint for that entry (or the dismiss endpoint for a dismissal), shows a Queue entry resolved toast, refreshes the queue, and closes the dialog. The entry's status becomes Classified (or Dismissed), and the row records its resolution type and the time.

Held purchase order line items catch up

A SKU can reach this queue because a purchase order imported a code nobody had classified yet. Those PO line items are saved with no SKU attached and held, so their quantity counts toward nothing while they wait.

Confirming a classification links them automatically. Every PO line item still holding that code is pointed at the SKU you just created and flipped to resolved. From there the SKU exists, so on-hand fills from ShipHero's available count on the next pull. You do not need to re-import the PO or enter any stock by hand.

Kits link through their base unit

A PO line item can point at a Base SKU or a Case SKU, never at a Product SKU directly. When you classify a code as a Product SKU, held line items link to the Base SKU behind it. If the kit maps to more than one Base SKU, or to none, the line items stay held rather than guess, and someone needs to link them by hand.

Reclassify or undo

Made the wrong call? On a Classified row, click the amber undo arrow to reset it. The entry returns to Pending so you can review it again.

Reset is available on classified entries only. Switch to the Pending tab after resetting to reclassify the SKU. Dismissed entries stay dismissed.

Quick reference

Run a SKU sync: how new SKUs reach this queue.
Settings feature guide: the screen in context.
SKU Sync database tables: where these decisions are stored.
Glossary: Base, Case, and Product SKU definitions.

On this page