Operating the reporting sync

Assemblified answers your sales reports from its own copy of your Shopify orders. That copy is refreshed on a schedule, and like any scheduled job it can fall behind. A connected assistant can check where it stands, and with write access refresh it and restart it when it has stopped.

What it takes

Checking the sync needs nothing beyond a connection. Refreshing it or restarting it needs write access: either an API key created with read & write scope or a web-chat connection granted read & write when it was linked. See API keys and Connect claude.ai or ChatGPT.

This is the same thing the Settings → Tools → Reporting page shows and the same two buttons it offers. Nothing here is plan-gated.

Why a report can look wrong when nothing is wrong

A sales report can only count the orders Assemblified has a copy of. So a thin report usually means one of three things, and none of them is a broken report:

The history does not reach that far back. The copy starts at a certain date; a period before it is empty because there is nothing there, not because nothing sold.
It is behind. Last night’s refresh has not run yet, or ran before today’s orders came in.
It has stopped. After a run of failures Assemblified stops scheduling refreshes rather than retrying forever, and the copy goes stale from that day on.

The check below tells the assistant which of the three it is, which is why it is worth asking before you go looking for a problem in your data.

Checking the sync

“My March sales report looks low. Is my order data actually up to date?”

The assistant gets back: how many orders are in the copy and how far back they go, when they were last written, whether a refresh is running right now, how the last one ended (with its error, if it failed), when the next one is due, and whether the schedule has stopped. It also gets how far back the manufacturing side’s own history goes, which is the same question for build and consumption reports.

A store that has never synced answers zeroes rather than an error. That is a useful answer too: it means the first load has not happened yet.

Refreshing now

With write access, the assistant can start a refresh instead of waiting for the nightly one.

Two things to expect.

It returns before it finishes. Starting a refresh hands back a reference to the run, not the result. The assistant should check the status again a little later to see how it went, and it should tell you that rather than claiming your reports are updated the moment it asked.
One at a time. If a refresh is already running, the request is refused with “already running” — which is an answer, not a failure. The right response is to wait and check the status again, and an assistant that keeps retrying in a loop is doing it wrong.

Restarting a stopped sync

If the schedule has stopped after repeated failures, the assistant can restart it, and the next refresh is queued straight away.

Restarting something that was not stopped does nothing, and says so. It is not an error and nothing is harmed, so the assistant may do it without checking first.
It restarts the schedule, not the cause. If whatever was failing is still failing, Assemblified will stop again after the next run of failures. Ask the assistant what the last error was before you assume it is fixed.

What it will not tell you

The sync covers orders. It does not fetch products, stock levels or bills of materials, all of which the assistant reads live and which are never out of date in this sense. If a stock figure looks wrong, the reporting sync is not where to look.

Running the reports themselves

This page is about the freshness of the data. Running the reports is a separate thing the same connection can do, on any plan and with no write access: list the report catalogue and run a report over a period, bucketed and location-scoped.

See Operating reports.