Using Shopify order tags as a job ledger

Short answer: write the tag last, after the work has actually succeeded, and check for it before starting. That single rule makes an integration safe to crash, safe to restart and safe to run twice, without a database. It works because Shopify's order record is the one piece of state both your code and a human can see, and a half-finished job simply has no tag.

Any integration that processes Shopify orders eventually faces the same question: how do you know what you have already done?

The instinctive answer is a database. A table of order IDs and statuses, which you write to as you go.

For a lot of automations you do not need one, and adding one makes the system worse. The order itself can carry the record.

The problem, precisely

Your process runs. It picks up order #1042, downloads a file, validates it, writes it to a folder, and the machine loses power halfway through.

On restart, what does it know?

With no record at all, it either reprocesses everything from the beginning of time or skips forward and loses orders. With a record written at the start, #1042 is marked "processing" forever and nobody knows whether the file landed. With a separate database, you now have two sources of truth that can disagree, and the interesting failures are exactly the ones where they do.

What you want is a record that is true by construction: present only when the work genuinely finished.

Tag as ledger

Shopify orders carry tags. They are visible in the admin, filterable, searchable, writable through the API, and they are part of the order — not a parallel system.

The rule is one sentence: write the tag as the last action, after every side effect has succeeded.

That ordering does all the work.

• Process crashes before the tag is written → the order has no tag → the next run picks it up and redoes it. Correct.
• Process crashes after the tag is written → the work was already done → the next run skips it. Correct.
• Process runs twice concurrently → both do the work, the second one's writes are idempotent, both try to tag → harmless. Correct.

There is no state that means "maybe". An order is either tagged and done, or untagged and pending.

The cost of this design is that a crash means redoing work, so every side effect must be safe to repeat. Writing a file to a deterministic path is safe. Sending an email is not. That constraint is the real one, and it is worth knowing before you choose this pattern.

What should the tags say?

Keep them few and mechanical. A tag vocabulary that grows becomes a state machine nobody documented.

A working set:

• wf-queued — processed successfully and handed to the next stage
• wf-review — processed, but something failed validation and a human needs to look
• wf-error — the process itself failed in a way worth flagging

Three tags cover most workflows. Prefix them so they are obviously machine-written and never collide with the tags merchandising uses.

If you need more than the outcome — which check failed, how many files, when — put that in a metafield and keep the tag as the flag. Tags answer "is this done"; metafields answer "what happened".

Reading it back

The check before starting is a tag lookup, and the query is the same one that drives the poll:

status:paid AND NOT tag:wf-queued AND NOT tag:wf-review

That single query is the work queue. Not a table, not a job runner — a filter over orders Shopify already holds.

It also means the queue is visible in the Shopify admin. Anyone can open Orders, filter by tag, and see exactly what is pending, what went to review and what is done. No dashboard to build, no access to grant, no second system to explain to whoever covers when you are away.

That last point is worth more in practice than it looks on paper. Most small automations fail not because the code was wrong but because nobody except the person who built it could see what was happening.

When are tags the wrong answer?

Be honest about the limits.

High frequency updates. Tag writes are API calls against your rate limit. Once per order is nothing. Several times per order across thousands of orders a day starts to matter.

Ordering between two concurrent writers. Tag updates are read-modify-write on the whole tag set. Two processes tagging the same order at the same moment can lose one of the tags. If more than one writer touches an order, you need real coordination, not tags.

Anything needing a timestamp or a value. Tags are flags. "Processed at 14:32 by worker 3, attempt 2" is a metafield.

Large ledgers. Hundreds of tags per order is an abuse of the field and makes the admin unusable for the people who actually merchandise the store.

Anything a customer might see. Some themes and apps surface order tags. Check before writing something internal into them.

The pattern fits single-writer, once-per-order, outcome-is-a-flag automations. That describes a large share of order automation, and almost none of a real order management system.

Tags, metafields, or a database?

The combination most of our builds use: a tag for the outcome, a metafield for the detail, and no database at all. The store is the system of record, which also means that when the automation is eventually retired or replaced, the history stays with the orders rather than disappearing with the service.

The rule, restated

Write last. Check first. Make every side effect repeatable.

Three sentences, and they replace most of what a job queue exists to do — for the specific case of once-per-order work with a single writer.

This is the same reasoning behind polling Shopify rather than using webhooks: design for the crash, not for the happy path, and prefer the failure mode where work is repeated over the one where work disappears.

We build Shopify order automation that runs on the client's own hardware, with no database to maintain and no monthly fee. Fixed price, source code handed over.

Got a process that quietly reprocesses or skips orders? Book a free 30 minute call. Or read how we built an order-to-print-file pipeline, or see our app development work.