Using Priorly

Four kinds of thing: products, collections, pages and blog posts. Nothing else — see step eleven for the list of what is deliberately outside, and why.

For a product it keeps the title, URL handle, description, status, vendor, product type, tags, options, every variant with its price, compare-at price, barcode and position, the search engine title and description, the theme template, and custom fields. For a collection: title, handle, description, sort order, the products in it, their manual order, the automatic conditions, SEO fields, template and custom fields. For a page: title, handle, content, whether it is published, template and custom fields. For a blog post: title, handle, content, summary, author, published state, tags and custom fields.

Products and collections are recorded the moment they change. Shopify tells the app as it happens, so a version exists within seconds of somebody pressing save — and a change made and undone twice in an afternoon leaves three versions, not one.

Pages and blog posts are different, and the difference matters. Shopify offers no such notice for them, so the app finds their changes by comparing your store against its own records — which happens when you open the app, and at most once a day. A page changed and changed back between two of those checks leaves no trace, because at both checks it looked the same.

That distinction is shown on every screen where it applies: products and collections are marked Recorded live, pages and blog posts Checked, not watched. It is not a limitation the app hides in a footnote.

The first thing a fresh install does is take a snapshot of the whole catalog. On a small shop that is a minute or two; on a large one it runs in the background while you carry on with something else, and the dashboard says how far it has got.

Everything after that snapshot is history. Each item's first row is labelled First snapshot, so it is always clear where its record begins rather than where the item itself began.

Nothing before it exists. Shopify keeps no version history of its own and hands none over, so the day you install is the earliest day any plan can reach.

There is no version of anything from before the day you installed, on any plan. That is the whole argument for putting it on before you need it rather than the morning after — the app cannot show you a day it was not there for.

From then on two lines limit how far back you can go, and the later one wins: the snapshot itself, and how many days your plan keeps. On the free plan, 30 days after installation the snapshot stops being the limit and retention starts being it. The app names whichever is currently binding on the dashboard rather than leaving you to work it out.

The dashboard is every recorded change, newest first: what changed, what kind of thing it is, where the change came from, and when.

Each row names its source, and the four are worth knowing apart. Changed in Shopify is the ordinary case — somebody or something edited the item and Shopify said so. First snapshot is the row that started this item's record. Found by a check for missed changes is one the app noticed by comparing rather than by being told, which is how pages and blog posts always arrive and how anything missed during an outage comes in. Restored is a change this app made itself, at your request.

Search takes a name or a URL handle. Two filters sit beside it: one for the kind of thing, one for the kind of change. Any row opens that item's full history.

Every row carries the item's picture, which is there so you can recognise a product without reading its SKU.

Pictures are shown, never written back. Restoring an item does not restore its images — the app keeps the link to an image, not the file, and a recreated item comes back without them.

The same screen works on a phone, which is where you will be when somebody calls about it — the table folds into rows rather than scrolling sideways.

Check for missed changes runs a comparison on demand. It is the same sweep that runs on a schedule, and it is what you press when you have just been told something changed and you want to be sure the record has it.

Open any row and you get that item's versions, newest at the top, each with its date and where it came from. Current marks the one live in your store right now, and the header says how many versions are on file.

A version is what the item held at that moment — not a list of differences, the whole state. That is why any version can be put back without needing the ones in between, and why the app can show two versions side by side however far apart they are.

A deleted item keeps its history and its page. The top of the screen says it is deleted, and the newest version is the route back: restoring it recreates the item rather than editing one.

Versions older than your plan's retention are removed, and the app warns before that happens rather than after — a notice names the date and how many versions are about to go, so there is a week to act or to upgrade.

Review and restore opens a preview before anything is written. Every field that would change is listed with the value in your store now against the value being restored, and each row says what kind of change it is: changed, added, or removed.

Differences are marked inside the text, so a description that lost one sentence shows you the sentence rather than two paragraphs to compare by eye.

The version that is live now stays in the item's history. A restore is itself a change, recorded like any other — which means the thing you just replaced is one click from coming back, and a restore made by mistake is not a one-way door.

On the free plan the preview lists every field that would change but hides the values behind dots. The shape of the change is visible — which fields, and how many — and reading the values or writing them back is what the paid plans add.

A restore is written as one operation. If part of it fails, the app says which part rather than reporting success and leaving you to find out later.

Everything in that preview starts ticked. Untick a row and that field keeps the value it has now, so a restore takes exactly the fields you chose and leaves the rest of the item alone.

That is the everyday case: last Tuesday's price was right and last Tuesday's description was not, so you take the price and leave the description alone. There is also a Restore button on each row, for when it really is one field and you would rather not untick eleven others.

Some rows cannot be separated, and the preview joins them with a line down the side to say so. Rows belonging to the same variant move together, and all of a product's variants move as one list, because Shopify stores them as one list — putting last month's variants beside today's options is a product Shopify would refuse.

The same is true of a collection: it is either manual or automatic, so its member list and its rules move as one. A member list restored against live rules would be silently overwritten by the rules a moment later.

Sometimes no single version is right. The description was correct a fortnight ago, the price was correct yesterday, and restoring either version means accepting the half of it that was already fine.

Build from history offers every field with every value it has held, each dated by the stretch it held it for rather than by the moment it appeared — so a row reads "in place Aug 3 – 5", which is what you are actually choosing on. A value the field returned to later is offered once, from its most recent stretch, rather than three times over.

Pick one value per field. Anything you do not touch stays on the value your store has now, which is shown as the first option and marked as current — so an untouched field is a deliberate keep rather than an oversight.

The confirmation is two tables: what changes, with the current value against the new one, and what stays as it is. It names fields rather than a date, because the result is a mix and calling it "the version from the 3rd" would be a lie the timeline then tells forever.

After it is written you get the list of fields that moved, a link into the item in Shopify, and the way back — the mix is a change like any other and can be undone.

Two pairs cannot be split here either, for the same reasons as the previous step: a product's options travel with its variants, and a collection's rules travel with its members. Blog posts have no picker at all, because Shopify offers no way to write their fields back one at a time.

It reads the newest 200 versions of the item. On a busy product on the long-retention plan there can be more, and the screen says so rather than quietly showing a shorter list.

Deleted items are listed on their own page with the date they went and what kind of thing they were. Search and the type filter work the same way as on the dashboard.

Restoring one recreates it from the last version on file. For a product that means its variants, prices, barcodes, options, tags, SEO fields and custom fields — and its place in every collection it belonged to, in the position it sat in. For a collection it means its rules or its member list, and the order. Pages and blog posts have nothing else in the store pointing at them, so putting the item back is the whole job.

A product comes back as a draft and a page unpublished unless you say otherwise. The tick is there because "is this going straight onto the storefront" is a real question at that moment, and the alternative is racing the shop to hide it. A collection is not offered the choice: its visibility lives in publications this app does not record, so the tick would do nothing.

The web address survives, so links and search rankings keep working.

The internal id Shopify gives it does not survive. A recreated item is a new id, and anything that pointed at the old one — past orders, other apps' data, an export you made last year — still points at nothing. Nothing can change that: the id is Shopify's to issue.

If some of the reconnecting fails — a collection that no longer exists, for instance — the app says which parts could not be reconnected instead of reporting a clean success.

When an import or a bulk edit has been through the catalog, one item at a time is the wrong tool. Undo this period takes a window of time and puts back everything that changed inside it.

The app also notices for you. Twenty-five or more changes recorded in one stretch — a stretch ends after five quiet minutes — raise a notice on the dashboard naming the count and the times, and its button opens the undo with the window already filled in, in your store's own clock. The notice appears on every plan, because a shop that cannot undo a period still needs to know four hundred products were rewritten overnight. It can be dismissed, and dismissing it does not hide a later one.

The screen lists what it would do before doing it: what goes back, what is already as it was, and what was created inside the window. The last of those cannot be put back — there is no earlier version of a thing that did not exist — so the honest answer is to name them and leave them alone.

A window that comes up empty is worth a second look before you believe it. The times are your store's own, so a window typed from your clock is off by the difference between them. Pages and blog posts are only found by comparison — at most once a day, hourly on the top plan — so a change made inside the window may not be recorded yet: run a check for missed changes and open the window again. A gap covering those hours means the record has a hole there rather than a quiet stretch. And a window earlier than the first snapshot, or older than your plan keeps, has nothing behind it to find.

Anything deleted inside the window is treated as a deletion to reverse, which means it comes back under a new id like any other undelete.

Undoing a period is on the top plan. The notice that finds one is not.

Sometimes a change never reaches the app. Those windows are shown as gaps, with the hours they cover and the reason for each, rather than being smoothed over — a history with a silent hole in it is worse than one that says where the hole is.

There are four reasons, and they say different things. Change notifications weren't arriving and Shopify couldn't deliver a change notification are outages, ours or theirs. The first snapshot didn't finish means the baseline was interrupted and the record starts later than it should. The app lost permission to read this data means a scope was removed — usually by an uninstall and reinstall, or by a permission change that was not accepted.

Check for missed changes closes what can still be closed, by comparing your store against the record. It cannot recover a value that was changed and changed back inside the gap, because there is nothing left in the store to compare against; what it does recover is everything that is still different.

Once a gap is closed the app says so plainly — everything after a named date is complete — so the record's own reliability is a fact on the page rather than an assumption.

Six things are outside the app on purpose, and it carries the list itself so the boundary can be checked on a quiet day rather than discovered on a bad one.

Orders and customers are not recorded at all: they are financial and personal records, and an app that held them would be holding personal data it has no need for. Themes are a different job with different tools. Other apps keep their settings in their own systems, where this app cannot see them. Inventory quantities move constantly, and putting an old number back would be wrong more often than right. Images are the one that surprises people: the link to an image is kept, the file is not, so an item brought back from the deleted list returns without its pictures and they have to be added again in Shopify.

The same list lives inside the app, on its coverage page, next to what each type does record — so it can be read before you rely on any of it.

Free records the whole catalog and keeps 30 days of it. Everything is readable and comparable, including the preview of what a restore would change — the values are hidden, the shape of the change is not. That is enough for the history to already be there on the day something goes wrong.

Basic is $12 a month: restoring, undeleting, and 90 days kept.

Advanced is $29 a month: undoing a whole period, checks for missed changes every hour rather than once a day, and 365 days kept.

No plan is priced by catalogue size, so the bill does not change because the shop grew — the price is per shop, not per product. Both paid plans start with a 14-day free trial, and one trial per shop: switching plans does not start another.