Data explorer

Data in the sidebar opens the record browser. It answers one question for every record a migration has touched:

Is what’s in Shopify the same as what we prepared for it?

Each row gets a one-word verdict in the Check column, and you can open the row to read the source record and the mapped output side by side and see exactly where they diverge.

The Check column

This is the column to read first. Everything else on the screen is a way of narrowing down to a set of rows and then looking at one of them.

Check	What it means	What to do
Match	The record was pushed and Shopify holds exactly what was prepared for it.	Nothing.
Drifted	The push landed, but something came back with it — a link Graftport had to drop, a field Shopify refused to change. Shopify now holds almost what was prepared.	Open the row. The note at the top says what was dropped and names the field.
Failed	Shopify rejected the record, so the change didn’t land.	Open the row, read the note, fix the mapping or the source data, and re-run.
Pending	Nothing to compare yet. The record has never been pushed, was only ever prepared by a dry run, or has changes the next run still has to send.	Run a load, or a dry run first if you want to see the output without writing.

Drifted is the one that surprises people. A drifted record is not a failure — the run reports it as a success, because the write did succeed. It means Shopify and Graftport disagree about part of the record. The most common cause is a reference to something that hadn’t been created yet when this record was pushed; running again once the other record exists usually turns it into a Match.

Choosing what you’re looking at

The bar across the top narrows the set of records, left to right:

Control	What it does
Migration	Data is always scoped to one migration. Switching resets the resource and run choices, because a different migration has different ones.
Resource	Products, customers, orders, … Each shows how many records have been extracted for it.
Source / Mapped output	Which side of the record the table shows. See below.
Run scope	Every staged record (the default) or the records one particular run touched.
Columns	Which fields the table shows. Each resource opens on a sensible default set.

The count beside the controls reads 120 of 4,317 records — how many are loaded into the page against how many are in scope. Scrolling near the bottom pulls the next batch automatically, and the footer carries a Load more button plus a running 120 of 4,317 loaded. It tells you when you’ve reached the end.

Source vs Mapped output

The same rows, read from two different sides:

Source — the record as the source platform returned it. The merchant’s own field names and values.
Mapped output — what Graftport sends to Shopify after the mapping runs. Shopify’s field names.

The columns and filters you set are remembered per resource and per side, because the field names differ between them. A filter you added on the source side doesn’t follow you to the mapped side, where that field doesn’t exist.

The field rail

The left rail lists every field the loaded records carry, with a fill rate — the percentage of those records where the field has a value. It’s the fastest way to spot a mapping that quietly produces nothing: a field sitting at 4% when you expected 100% is the whole diagnosis.

Each field has two actions: tick it to add it as a column, or use the filter icon to filter on it. The search box at the top narrows a long field list.

The fill rate covers the records loaded into the page so far, not the whole resource. The rail says so under the list. A 4% fill over 100 rows and a 4% fill over 100,000 are very different facts — load more rows before you draw a conclusion from one.

Filters

Add filter builds a condition against any field, or against the Check column itself. Filters combine with AND, and each one shows as a chip you can remove.

Operator	Available on
contains, is, is not, is empty, is not empty	Ordinary fields
contains, is empty, is not empty	List fields (tags, images, …) — matched against the members
is, is not	The Check column, against Match / Drifted / Failed / Pending

Matching is case-insensitive. Filtering on the Check column is the usual starting point: Check is Failed gives you the triage list, Check is Drifted gives you the “worth a look” list.

Reading one record

Click a row to open the detail panel:

The source ID and the verdict badge at the top, with the record’s Shopify handle underneath — or Not in Shopify yet.
The note, when there is one: the single line explaining a drift or a failure, and the field paths it names.
Source record — the full source payload as a collapsible tree.
Mapped output — what we send to Shopify, same shape. Any field the note called out is marked here, so you can go straight to it.

On a failed record the panel offers Open in the mapping editor, which opens the mapping already pointed at this record so you can correct the expression against the row that broke.

Typical uses

Before a load — switch to Mapped output, scan the columns for the fields that matter, and check the rail for anything unexpectedly empty. Pair this with a dry run so payloads exist without anything being written.
After a load — filter Check is Failed, work through the notes, then filter Check is Drifted for the softer problems.
“Why is this product wrong in Shopify?” — filter the source side on the SKU, open the row, and read the two payloads against each other.
“Did that field ever make it?” — put it on screen as a column and read its fill rate.

What it doesn’t do

The Data explorer is read-only. Nothing here writes to Shopify, changes a mapping, or starts a run — it shows you what happened so you can decide what to do next.