User Guide

The big picture

A wine flows through Trellis in a few stages. Facts about the physical wine (alcohol, weight) come in from our purchasing system, live on a single shared SKU, then get combined with per-store marketing data and pushed out to each Shopify storefront. Shipping systems stay in sync along the way.

Two layers of data: SKUs vs Product Data

This is the most important concept in the whole section. There are two records behind every wine on a storefront:

• The SKU — one shared record per physical wine, used by every store. It holds the facts that never change between stores.
• The Product — one record per store that sells that wine. It holds the store-specific marketing and pricing. Several products (one per store) all point at the same SKU.

Knowing which record owns a field tells you where to edit it:

Where the data comes from (automatic syncs)

Two outside systems keep parts of the catalog in sync automatically, so you don't hand-enter them:

Precoro → SKU (alcohol, weight, BOL & received dates)

Precoro is our purchasing system. As receipts are processed, Trellis reads each line item's alcohol % and weight, plus the receipt's BOL Date (most recent Bill of Lading) and its received date (the receipt date, recorded with the store it came from), and writes them onto the matching SKU — matched by SKU code (and its parent/original codes). This happens continuously in the background, and can also be triggered for a store from the admin tools. The most recent BOL and received dates are kept (they only advance forward); weight only moves forward to Linnworks (see below).

SKU → Linnworks (name, weight, alcohol declarations)

Linnworks is our shipping/inventory system. Each SKU can be linked to a Linnworks inventory item; once linked, the SKU's name and weight are pushed there. Linking happens via the “Add To Linnworks” action on the SKUs page or the Bulk Add To Linnworks page. Linking never overwrites an existing Linnworks item — it links to a matching one if it exists, otherwise creates a new one. When Precoro changes a SKU's weight, that new weight is pushed onward to Linnworks too.

Alcohol declarations on the Linnworks item

Whenever a SKU is added to Linnworks or synced to it, Trellis also puts three extended properties on the inventory item — this is what tells the carrier the parcel contains alcohol:

• fedex_signature — an adult signature is required on delivery.
• carrier_alcohol_declaration — the parcel is declared as alcohol.
• alcohol_percentage — the strength, taken from the SKU's Alcohol %.
• bottle_size — taken from the SKU's Bottle Size. Unlike the three above, this goes across for every SKU that has a size, alcohol or not — the warehouse needs to know what it's packing either way.

These are merged into whatever the item already carries: nothing is added twice, a value that has gone out of date is corrected, and any other properties on the item are left untouched. Editing only the Alcohol % is enough to push the change on its own. A SKU with no Alcohol % recorded simply doesn't get that third property — the other two still go.

The pages

SKUs /products/skus

A SKU code can't be reused. Adding a SKU — or copying one into a new record — with a code the catalog already has is refused, and the message names the wine it clashed with, since the usual cause is re-adding something that's already there. Note there are existing duplicates: legacy imports were allowed to create them and they need cleaning up by hand, so this stops new ones rather than fixing the old.

The shared baseline catalog. Search and filter SKUs, create new ones (name and vintage are required; bottle size is a dropdown of the 21 standard sizes with an Other… option for case sizes like "12-Pack", and defaults to 750mL when left blank), edit the SKU-owned wine attributes, see every store product linked to a SKU, link a SKU to Linnworks, and start a merge/migration. A SKU is active, disabled, or merged (absorbed into another SKU but kept for history). The list also shows the SKU's BOL Date and Last Received date (with the store) from Precoro.

Putting a SKU on the Inbound queue. The + Inbound button, among the row's other action buttons, adds this wine to Inbound without going to that page and searching for the same SKU again — useful when the wine you're looking at is one you already know is on order. It asks for the store (required — an inbound row belongs to one storefront), and optionally the Source, PO # and Ordered Qty (free text, like the column on the Inbound page — “2 cases” and “12” are both fine); everything else about the row is filled in on the Inbound page afterwards, and the row is identical to one added there.

Editing a wine's data. The Edit dialog now covers every field the SKU owns: the physical facts it always had, plus Wine Data (bottle size display, varietal, metavarietal, blend), Origin (country through vineyard) and Winemaking (winemaker, fermentation, aging, oak, case production, farming method, dosage, disgorgement date, time on lees). These are the same fields as the SKU-marked cells in the Product Data Job editor, working the same way — so a wine's data can be fixed without a job existing for it. The Show legacy fields link (previously "Show all fields") hides what it always did — the old identifier codes, vendor, historical cost and PO — and now also the export defaults (carrier alcohol declaration, FedEx signature, category, product type, gift card, inventory policy and tracker), which every wine carries the same value for and almost nobody needs to change.

Pushing a SKU change to Shopify. Editing a SKU changes Trellis, not the storefronts. The Update Shopify button — shown on any wine that is already published somewhere — sends the SKU's data to the listings that exist. It opens a review step first: every field that would be sent, with the value it currently holds, and every store the wine is on. All fields start ticked; untick anything you don't want to send. A field with no value is shown marked (empty) and pushing it clears that value on the storefront, which is sometimes exactly what you want and never something to do by accident.

Stores are updated one at a time and each reports as it finishes, so a slow or failing storefront doesn't hold up the others. A store that failed keeps its tick and the button becomes Retry failed stores — pressing it again retries only those, never re-sending the ones that worked. Failures are explained in the same plain language as the job editor's upload errors, with the raw Shopify message behind details.

A store that has product data but has never been published is listed with that reason and can't be pushed to — there is no listing to update, and publishing one for the first time is still the Product Data Job's job, because that's where the data and pricing checks live. Only the wine's own fields go: titles, descriptions and prices belong to each store and are edited in the job editor.

Every push is recorded. Open Show History in the Edit dialog and you'll see two lists: the field changes (what the value became, and who changed it) and the Shopify uploads — when the wine was sent to a storefront, by whom, which fields went, and by which route (this button, a product data job, a Marathon correction, and so on). A field can be right in Trellis and never have been pushed; that's the gap the two lists together close.

It remembers the Source and PO # you've been using. Both boxes suggest what you've already typed on this page, so a shipment of ten wines on one purchase order needs the PO typed once. Ordered Qty is deliberately not remembered — a count belongs to the wine in front of you, not to the shipment — so it starts empty each time. The list is kept on your own machine and lasts until you close the browser — nobody else sees it, and it isn't kept beyond that sitting. The dialog closes as soon as the row is created, and the confirmation appears on the SKUs list above the table — naming the wine and the store, with a link through to Inbound. It stays until you dismiss it or add another wine rather than fading away, so the link is still there when you reach for it. Adding the same wine for a second storefront just means pressing the button again: the boxes start empty each time, so a PO is never carried onto a wine you didn't choose it for, but everything you've typed is one click away in the dropdown.

SKU Suggestions /products/sku-suggestions

"Wines like this one." Type a SKU code and the page lists the SKUs whose tasting profile sits nearest to it — nearest in taste and origin, not in name. A profile is built from two things: the wine's own facts on the SKU (type, grape, origin, producer, winemaking, alcohol) and what its reviews say it is like — body, acidity, tannin, sweetness and oak on five-point scales, the fruit family, aromas, flavours, a few style words such as mineral or age-worthy, and a one-line summary. Only what the reviews actually say is recorded; a wine with no reviews gets a profile from its facts alone, and its review-derived fields read not stated.

Profiles are made in batches, on purpose. Each one costs an AI read of the reviews, so SKUs are queued for it by hand in the database rather than from a button, and the Generate Profiles button at the top builds the next ten off that queue. The counts beside it say how many profiles exist and how many SKUs are still waiting. A SKU you search for that has no profile yet gets one built on the spot, so you never have to wait for the queue to reach it.

Each suggestion shows a Match %, the wine's facts, its Scores (the top score and the critic summary, worked out from every review on the SKU the same way publishing works them out for a listing), where it is Available right now (one chip per storefront that has it on offer, with the quantity and price the Private Client pages would quote), how long that stock has been sitting (Age, the same inventory age Offer Inventory shows), an In common list (same grape, the deepest shared region, alcohol within half a point) so you can say why it is similar, and the wine's own summary. Tick same wine type only (the default) to keep reds with reds; untick it to let a similarly styled white through. The profile is a distillation, so both the searched wine and every suggestion carry a Reviews control that opens the critics' actual reviews, best score first — read those when a match looks surprising.

Linnworks Link /products/linnworks-link

A shared worklist between whoever spots the problem and the warehouse team: wine that still needs linking in Linnworks, or wine whose quantities need correcting on a link that already exists. Add rows by hand with + Add Row — search for the SKU by code (or untick SKU code only to search by name), then fill in as much as you know: PO, Brand, Location, Quantity and Notes.

Every row says which of the two jobs it is. LINK means the link doesn't exist yet and needs creating; UPDATE means it exists and only the quantity is wrong. The PO is optional on both — worth filling in when you know it, and never a reason a row can't be added.

Importing a sheet. Import CSV at the top takes a spreadsheet with a SKU column (required) plus Name, PO, Brand, Notes, Location, Quantity, Alcohol and Weight. The first four are exactly what a Product Data Job's Download CSV gives you, so that file is the natural starting point. Choose the action for the whole sheet, press Check, and you get a summary before anything is written: how many lines matched a SKU, how many matched none, how many need you to choose, and which cannot be imported and why. Lines that match exactly one SKU — and lines that match none — import on their own. Where several SKUs share a code you are shown the candidates and asked which one — each listing which stores already have product data for it, or no product data, which is usually what tells them apart: the SKU the stores already sell under is the one a row for that brand belongs to. Leaving the row out is the default, because filing work against a guessed wine is worse than not filing it. A wine already on the queue is not added again. Each line is checked against the rows already waiting, and one whose wine already has an open row for the same action is reported as “already on the queue” rather than appended — so re-running a sheet after correcting a few lines no longer doubles the work, and a sheet that lists the same wine twice imports it once. A row already marked Done does not block a re-import (that work is finished; the same wine on a later sheet is usually a new shipment), and a pending LINK does not block an imported UPDATE, because those are different jobs. The review screen lists what it matched, separately from what it could not import. Rows with no matching SKU come in as they stand, marked no SKU and tinted so they stand out, carrying the sheet's alcohol and weight since there is no SKU to read them from. A few brands are written differently on the sheets than the storefronts are named — Last Bottle means Last Bottle Wines, The Yount Room means Yount Room — and those are translated as they come in; the rest match on the name itself, ignoring case and spacing. A brand that still isn't one of our storefronts is kept too, exactly as the sheet spelled it — the Brand column shows it as … (not a storefront) and you can pick a real one later.

Find a row with the SKU box — it matches the SKU code only (a partial code is fine: 1008 finds 1008784), not the wine name, since you're usually reading a code off a bottle or a packing list. Delete on a row takes it off the queue after a confirmation naming the wine: a row here is a note to the warehouse rather than a record of anything, so a wrong SKU or work that turned out not to be needed is removed rather than marked done — marking it done would say it was linked, which is the one thing it mustn't say. Nothing in Linnworks is touched either way.

Narrowing to what still needs doing. Three tick-boxes under Needs attention filter the list: Not listed in any store (Linnworks has no Shopify channel mapping, so the item's inventory syncs to no storefront — the core of what this page is for), Missing product data (no storefront holds product data for that SKU), and No stock available (stock has been checked and there is nothing to ship). Tick several and they narrow together. Rows with no SKU match none of them — they have no listings, product data or stock to speak of, and the SKU column already marks them. The stock one deliberately leaves out rows nobody has checked: “we looked and there is none” and “nobody has looked” are different answers, and a row only gets stock figures once it has been through Sync Selected.

Mark each row NEW or DONE as you work it; the page opens filtered to New, so marking one done takes it off the list. Status now sits beside Action, and to clear a run of rows in one go tick them and use the Set status… dropdown that appears next to Sync Selected, then Apply. That reaches every selected row, including ones with no SKU — Sync skips those, but marking one done after dealing with it by hand is exactly what you want. The two buttons count different things for that reason: five rows selected with two lacking a SKU reads Sync Selected (3) and Apply (5). Filter by status and by action, and sort by date added. Alc and Wght sit next to the wine's name, and are read straight from the SKU record rather than copied onto the row, so correcting the SKU corrects what the warehouse sees. Action and Brand are set when the row is added and then read only: which job this is, and which storefront the wine belongs to, are what the warehouse routes by, and a dropdown sitting open on either invites a change nobody meant. The exception is a brand that never resolved — a row whose sheet named something that is not one of our storefronts keeps its picker until somebody answers it, which is the whole point of it being there. The Actions column opens the same Linnworks item view used elsewhere in Trellis — the warehouse item's numbers, its extended properties and its channel mappings — so you can check what Linnworks actually holds without leaving the page.

Product Data /products/data

A searchable, read-oriented index of every per-store product. Search by title or SKU, filter by status (DRAFT / ACTIVE / ARCHIVED), and open a product to see its full edit history. Products linked to Shopify show a quick link out to the Shopify admin page.

Product Data Jobs /products/data-jobs

Where the actual data-entry work happens, organized into jobs. A job targets one store and a set of products; you fill in their data in a spreadsheet-style editor, then publish the finished rows to Shopify. Each job tracks three independent areas so different people can see at a glance what's left:

• Data Complete / Needs Data — wine attributes, region, description.
• Buying Complete / Needs Buying — price, compare-at, cost.
• Warehouse Complete / Needs Warehouse — weight & alcohol on the SKU.

When you create a job you first pick the store, give it a name, optionally assign it to someone, set a due date and add notes (free-text context for whoever works it), then add products either by searching SKUs one at a time or by uploading a CSV. Search matches the SKU code or wine name; tick SKU code only to match just the code and skip the fuzzy name search (it stays on as you keep adding SKUs until you untick it). The Upload button first shows which columns the file may contain: a required SKU column, plus optional Price, Cost, Compare Price, and Web Price columns (all matched case-insensitively; any other column is ignored). When you add each product, price/compare/web price are saved onto the product for that store, and cost onto the shared SKU (so it's the same everywhere the wine sells). A CSV drops you straight into a list with one row per uploaded SKU: each shows the existing product for that store to add, the option to copy a new one from another store's product, or to create a fresh one — and codes not yet in the catalog get an inline Add New SKU. Picked or created products land in the Selected tab; save the job to start entering data.

New products start as DRAFT, so when you upload them to Shopify they arrive unpublished — nothing goes live until you set the product's Status to ACTIVE in the editor. You can change the status at any time.

The editor also helps you work faster: prefill a new product by copying wine data from the same SKU at another store, copy from a similar SKU (the ⧉ button on a row finds another wine — a different vintage, say — and copies its varietal, region, winemaker and the rest, letting you untick anything first; reviews come too when it's the same vintage), auto-populate attributes from the title with AI, and draft a store-styled description. Many cells show a small square in their lower-right corner — drag it down to copy that value into the rows below. Dragging the one on Country is special: it copies the whole region together (Country, Region, Sub Region, Appellation, Sub Appellation and Vineyard), since those levels only make sense as a set. If a SKU you need doesn't exist yet, you can add it inline while picking products. Each row also has two history buttons on the far right — PROD for that product's data history and SKU for the linked SKU's history — each opening a full change log of every field edit with its old and new value, who changed it, and when. Finished jobs can be archived; the list defaults to active jobs with a link to view archived.

Who can be assigned a job. Only people marked as a product data editor on their user profile appear in the assignee picker, and the server refuses an assignment to anybody else — so if a colleague is missing from the list, an admin needs to tick Product data editor on their profile in Users. Clearing an assignment is always allowed: leaving a job with nobody is a real state, and refusing it would strand a job whose editor has moved on. The one exception is the hand-back inside the editor, which sends a job up to whoever raised it for review — creators are often reviewers rather than editors, so that path doesn't need the flag.

Reassigning a job that came back. A job showing Needs review was handed back by its assignee, usually with a question on a row. When you pick a new assignee, Trellis asks whether to move the due date first — the original date was set for work that has already run past it, so sending the job out again unchanged starts the next person late against a date nobody meant. You can set a new date and reassign, reassign and keep the date, or cancel and do neither.

Assigning & scheduling jobs. On the jobs list, each job has an Assigned to dropdown and a Due date you can set right there (the due date sits just under the assignee). Use the Assigned to filter at the top to narrow the list to one person — or click Assigned to me for a one-tap view of your own jobs. A dedicated Due column shows each deadline and is sortable (click the header to float the soonest to the top); a job that's past due and not yet finished shows its date in red.

Downloading a job. Every job on the list has a CSV link — it downloads one row per product in the job, with a header row. You get the same columns the editor shows for that store, so it reads like the grid: the SKU code and wine name, whether that SKU is in Linnworks, the three statuses plus the upload status, a direct Shopify admin link for products that have been uploaded, all the product data, and all the SKU data (weight, alcohol, region, varietal and the rest). Reviews come through as readable lines, and the score fields as they're calculated for that store. Handy for checking a job over in a spreadsheet, or sending it to someone who doesn't use Trellis.

Job notes. Each job has a free-text Notes column on the jobs list, between Created and Action — context for whoever picks the job up, like which shipment it covers or what to watch out for. Click the cell (Add note when empty) to edit it in a dialog; clearing the box removes the note. Notes can also be filled in when the job is first created, from any of the three routes: the New Job page, Bulk SKU Matching, and Inbound → Create Product Data Job.

Finding which job a wine is in. The jobs list has a Find SKU box that answers "which job has this wine in it?" — it searches the rows inside every job, not the job names. Type a SKU code (1013373) for a direct lookup — a base code also finds its disgorgements, so 1006939 turns up 1006939-003 — or type a wine name (krug grande cuvee) for a fuzzy search that tolerates typos and accents. Matching jobs list the SKUs that matched underneath the job name. Only active jobs are searched; tick Search all jobs to include archived ones. If a wine is in the catalog but no job has it yet, the search says so explicitly rather than just coming up empty — so you can tell "no such SKU" apart from "nobody's worked on it yet".

Inbound /products/inbound

The job audit (only if you have the product data jobs audit permission). Each row on the jobs list gets an Audit link showing who edited which fields on that job, when editing started, how long it ran to the last edit, and whether that last edit landed before the due date. Fields written by the ✨ autofill are marked separately from ones somebody typed, because one click fills a dozen at once. Products → Job Audit is the same information rolled up: one line per editor with the jobs and rows they have worked on and their average times. Both only know about work done since auditing was switched on — an editor with nothing recorded has not necessarily done nothing.

A shared, spreadsheet-style queue of wine that's been ordered and is on its way to the warehouse — visibility for both the buying team and the warehouse team. Each row belongs to one store and one SKU, and carries a transit status: Ordered → In Transit → Arrived, plus an optional PO status (On Water / Needs Pro Forma). A second Data status tracks the other half of the journey — how far the wine's product data has got: Data Not Started → Data Job Assigned → Data Job Complete → Uploaded. Search the sheet by SKU code (the box matches the code only, not the wine name), filter it by store — and tick Make this my default store under the Store dropdown to have Inbound open straight to it every time (saved to your own profile; untick to clear) — by Transit and Data status (both sit in one box as checkboxes, so you can view several statuses at once — tick none to see them all), by rows that still need a photo, and by the Needs LW Link flag. SKU and Label Name stay frozen to the left as you scroll the sheet sideways, so you never lose track of which wine a row is — and clicking a row's ⋮⋮ handle highlights it, so you can follow one row across all those columns. Both statuses share a single Status column, stacked one above the other.

The last row is always blank: click + Search SKU… on it to open the Add a SKU dialog, pick the SKU there, then pick its store back on the row to add it. The dialog searches by SKU code by default — untick Search by SKU code only to search by full wine name instead. Every cell edits in place and saves as you go — order details (source, PO#, ordered qty, reorder), receiving details (delivered, date, received qty, exceptions, location) and free-form multi-line Notes. The three pricing fields — Landed Cost (always USD), PO Price and PO Currency — are the exception: they're read-only in the sheet, and clicking any of them opens a Pricing dialog that edits all three together (they only mean anything as a set). These deliberately mirror a SKU cost-history line, so the dialog offers an optional "Also save to this SKU's cost history" tick-box — off by default, keeping the numbers on the inbound row; tick it and it also records a proper cost line against the shared SKU, which becomes the cost used when publishing (Landed Cost is required for that). A CSV import never writes to the SKU — it just fills the row, so you can come back later and record the cost history properly. The SKU code, label name and unit come from the linked SKU record. The Product Data column shows a badge per store that already has product data for that SKU, each with that store's most recent upload date (or new if none do yet). Two admin flags round it out: Photo Taken (a tick-box on every row, whatever the store) and Needs LW Link — whether the SKU's Linnworks record still needs linking to Shopify — both filterable from the toolbar. Drag the ⋮ handle to reorder rows like a playlist.

You can also bulk-seed the queue with Import CSV: a dialog lets you pick which store to import for and shows the columns the file may contain (a required Universal SKU, plus optional Price, Currency, PO, quantities, delivery state and more). It creates one inbound row per line under the chosen store, matching each Universal SKU to the catalog (a delivered box marks the row Arrived). It's re-runnable. Rows whose SKU isn't in the catalog aren't dropped — they land in an Unmatched SKUs section at the bottom of the page, where Add SKU creates the SKU (prefilled from the row) and turns it into a real inbound row.

Tick the checkbox on any rows and a bar appears to run a group action. Today that's Create Product Data Job: it turns the selected SKUs into a new data job so their per-store product data can be filled in. A job targets one store, so the selected rows must all be for the same store; you're asked for a job name, plus an optional assignee, due date and notes — the same details you'd set on the New Job page — and a link to the new job appears when it's created. Those rows' Data status automatically moves to Data Job Assigned — you only set the later steps (Data Job Complete, Uploaded) by hand.

Bulk SKU Matching /products/skus/match

Upload a CSV of raw wine names and let Trellis match each to an existing SKU using fuzzy search. Review the suggestions, accept a match, pick a different SKU, or create a new one — and optionally prefill the new product from another store's product. Each confirmed row becomes a product ready to drop into a data job.

Merge SKUs /products/skus/merge

Consolidate duplicate SKUs. Search for the duplicates, choose one as the parent, and merge the rest into it. The children become merged (kept for history, hidden from new use) and point at the parent. Use this when the same physical wine was entered more than once.

SKU Migrations /products/skus/migrations

Move a store's products from an old SKU onto the correct SKU, and merge the old one underneath it. Pick the legacy SKU and the products to move, name the destination SKU (existing or auto-created from the legacy's attributes), and the job relinks each product and tracks its push to Shopify (with retry on failure). Use this when products were linked to the wrong SKU code.

Bulk Add To Linnworks /products/bulk-add-linnworks

Link many SKUs to Linnworks at once. Upload a single-column CSV of SKU codes (up to 100); the job runs in the background and shows live progress. Drill into results to see each row's outcome: Linked existing, Created new, Not in catalog, or Failed (with retry).

A typical workflow

Bringing a new wine to a storefront usually looks like this:

1. Make sure the SKU exists. Search the SKUs page; if it's not there, create it (or it gets created during Bulk SKU Matching). Alcohol & weight will fill in from Precoro as receipts process.
2. Create a Product Data Job for the store, and add the products (search & pick, Bulk SKU Matching, or quick-add a SKU inline).
3. Fill in the data in the job editor — wine attributes & region (Data), pricing (Buying); weight/alcohol (Warehouse) comes from the SKU. Use prefill / AI helpers to speed it up.
4. Publish to Shopify once Data & Buying are complete. The SKU's shared attributes are overlaid automatically at publish time.
5. Link to Linnworks (per-SKU button or the bulk page) so shipping has the right name & weight.

Status cheat sheet

Questions or something out of date? Let the engineering team know — this guide is kept in step with the app as features change.