- Nothing changes for you today: matching still takes in every SKU that has a counterpart, even beyond a plan's limit, and the Matching page looks the way it did.
- What's prepared: for a connected store, matching won't take in more SKUs than its plan includes. This isn't turned on yet.
- Once it applies: whatever is matched stays matched. New SKUs are added in SKU order until the limit is reached. The rest is listed in every store under "Not matched" with the new reason "Plan limit". If a matched SKU drops out, a waiting one moves up on the next run. Your first store has no limit.
- The Matching page will then tell you, before you click "Update matching", how many SKUs the plan includes and how many are matched, and after the run, how many are waiting.
- Once this applies, you'll read it here.
UM Multistore Sync
Keeps inventory in step across your Shopify stores and explains every number the app sets.
Plans from Free to $797 help articleslast changed Oct 9, 2026
Coming soon to the Shopify App StoreThe app's privacy policy
Changelog
What changed for merchants, newest first.
4
BetaPrepared, not active yet: the plan limit in matching
BetaYour first store is free, and each connected store has its own plan
- Plans now apply per store. Your first store doesn't need a plan, no matter how many SKUs are matched. Your first store is the one that has been in the group the longest: the store where you created the code to connect.
- Each store you connect to it needs its own plan, based on its matched SKUs. Up to 50, that's Free.
- Until now, one subscription covered all stores in the group, and the highest plan applied. That no longer holds: a subscription only applies to the store that holds it.
- The app counts per store: every SKU the store shares with at least one other store. With two stores, that's the same number as before. In these places, the app now calls it "matched SKUs".
- The "Plan" page tells you in every store which role that store has. In your first store, it shows where the connected stores stand, without a button to choose a plan. In a connected store, it shows its number, its limit, its plan and the plan that fits. The plans there are marked "Fits this store".
- The Overview page shows "… of … matched SKUs" for this store. In your first store, it says that the store doesn't need a plan and shows where the connected stores stand. The button at the top reads "View plans" there.
- If a connected store is over its limit, the notice "More variants than your plan includes" appears in every store of the group and names that store. "You're close to your plan's limit" only appears in the affected store.
- The "Stores" page tells you before you connect which store stays free and which one needs a plan. After that, it labels your first store "First store".
- If real-time sync can't be turned on because a plan isn't enough, the reason names the store in question.
- If a subscription is running in a store that doesn't need a plan, the "Plan" page and the Overview page say so. You can end it there with "End this store's subscription". The app never ends a subscription by itself.
- Choosing a plan and switching back to Free work as before, now in the connected store.
- Nothing has changed in syncing, matching or your data.
BetaNew prices, and the Pro plan now has a limit
- The paid plans cost less: Starter is $9 instead of $19, Growth is $29 instead of $49, and Pro is $79 instead of $99, each for 30 days. Free stays free.
- The limits of Free (50 variants), Starter (1,000) and Growth (10,000) stay as they were.
- Pro now includes up to 50,000 variants. Until now, Pro had no limit. From 80% of the limit, the Overview page shows "You're close to your plan's limit" on Pro as well.
- There is no fixed plan for more than 50,000 variants. For that, the Plan page has a line below the plans: "More than 50,000 variants? Contact us." The link takes you to the contact page.
- If your group has more than 50,000 variants, the Overview page and the Plan page no longer name a plan that fits. They point you to that line instead. Real-time sync that is already on keeps running. You can only turn it on again once the number fits a plan.
- Nothing has changed in syncing, matching or your data.
BetaMatching is saved for large catalogs
- Fixed: if your stores shared more than about 4,000 SKUs, every matching run ended as "failed". The app couldn't save the result within the time allowed. The previous matching stayed in place, or none at all if it was the first run.
- The app now saves the matching in larger steps. In a measurement on 2026-10-09 this took just over one second for 10,000 shared SKUs in two stores and about seven seconds for 50,000. That was measured on a test machine, without the time Shopify needs to deliver the catalogs.
- While saving, the "Matching" page shows the progress, for example "Saving the matching: 12000 of 50000 SKUs".
- Saving is still all or nothing. If saving does fail, the page now says: "The new matching couldn't be saved. The previous state still applies." Until now it showed either just an unexpected error with the technical message, or that Shopify couldn't be reached and that the app would try again on its own. The second wasn't true. Start matching again in that case.
- Sync: with very large catalogs, a running sync went minutes without a sign of life, 174 seconds for 50,000 SKUs in the measurement. From 180 seconds on, the page shows a run as "stuck" even if it's working. Now it reports during that phase too, and the "Sync" page shows "Recording the inventory read" with the current count. This doesn't make the sync any faster. We saw this in the measurement, not in any store.
- Nothing has changed in the matching rule or in your inventory.
6
Beta"Stores" and "Locations" are now under "Settings"
- The app's menu has five items instead of eight: "Matching", "Sync", "Activity log", "Settings" and "Plan". Until now, Shopify showed "Settings" and "Plan" only after a click on "View more".
- "Stores" and "Locations" are now pages under "Settings". At the top of that page there's a new "Setup" card with two rows. Each row shows the current state, such as "2 connected" and "1 location link", and takes you to the page.
- The first step is still one click: "Connect store" under "Getting started" takes you straight to connecting. The store that enters the code gets there the same way.
- "Overview" is no longer a separate menu item. The app's name in the menu takes you to the Overview page, as Shopify intends for apps. The "Overview" link at the top of the pages stays.
- From "Stores" and "Locations", the link at the top of the page takes you back to "Settings".
- Like "Stores", the "Locations" page now names the next open step under "What's next", with the reason and a button.
- The "Stores" page no longer shows the real-time sync direction. It's in the settings, where you also change it.
- If you haven't connected a second store yet, "Settings" shows the "Setup" card and a sentence about what will appear there later.
- The previous addresses of both pages redirect. A bookmark still gets you there.
- Nothing has changed in syncing, real-time sync or your data.
BetaNo more misleading error page while Shopify signs you in
- Fixed: if you opened the app's address directly in the browser instead of in the Shopify admin, you saw "Something went wrong" and the advice to try again in a few minutes. Nothing was broken. That message no longer appears there. You still open the app in your store's Shopify admin.
- As a precaution: if your sign-in expires while the app is open, Shopify signs you in again. While that happened, the app could show its own error page: "This page can't be opened this way". Now it lets Shopify go first. At most you'll see Shopify's short note "Handling response" in that spot until you're signed in again. We found this while measuring the built version of the app and haven't seen it happen in any store.
- If you have the app open and the server answers with an error when you navigate or save, the app shows its error page ("Something went wrong") and no technical text. Reload the page then.
- Nothing has changed in the app itself because of this.
BetaIf the request for a subscription fails, the Plan page tells you what happened
- Fixed: when Shopify didn't accept the request for a subscription, clicking "Choose …" left you with just "Unexpected Server Error" in the app's window and no way back. Now you're back on the Plan page. Above the plans it says "The switch to … didn't go through", with the reason, the next step and the technical message from Shopify for support.
- In that case your plan is unchanged, and nothing is charged.
- As a precaution: the app remembered a chosen plan before Shopify had accepted the request. If you already had a subscription, chose another plan and then didn't confirm on Shopify's page, the other stores in your group would have been on Free until you opened the app again in the paying store. Now a subscription only counts in the app once Shopify reports it as active, and your previous plan stays until then. We found this while reading the code and haven't seen it happen in any store.
- If you decline on Shopify's confirmation page or close it, the Plan page still shows your previous plan, with no error message.
- We noticed this on 2026-10-08 in a test store. Shopify declines every request there as long as public distribution isn't set up for the app yet. For that case the page now says that subscriptions aren't available in this installation yet.
- Security: if the subscription request was opened with a plan that doesn't exist, the value from the address appeared in the error message. The message now only says "Unknown plan."
BetaA page of its own when an address doesn't exist
- If you open an address of the app that doesn't exist, you now see a plain page: "This page doesn't exist". Below it are the way to the home page and a note on where you open the app. Until now a technical message appeared there.
- If something unexpected goes wrong while a page loads, including in the app in the Shopify admin, the page says so in one sentence and shows no technical details.
- The page is in German or English: in the app in the language of your admin, otherwise by the same rule as the start page and the privacy policy.
- Nothing has changed in the app itself because of this.
BetaBack to Free from the Plan page, and no more asking for your shop's address
- New: you can go from a paid plan back to Free on the Plan page. The Free plan now has a "Choose Free" button. The page then shows what applies afterwards, and only the "End subscription and switch to Free" button ends the subscription. Until now the only way was to uninstall the app.
- Shopify ends the subscription right away. If you've already paid for the current billing period, Shopify credits you for the unused part.
- If your group syncs more variants than Free includes, the page says so as a warning before you end the subscription. Nothing stops quietly in that case either: real-time sync that is already on keeps running, and so do matching and syncs.
- Only the store that holds the subscription can end it. In any other store of the group, the page tells you which store that is.
- If two stores in the group have a subscription, each can end its own. Until now the smaller of the two couldn't be changed in the app at all.
- As a precaution: an update from Shopify about an earlier subscription no longer changes your plan once a new one is running. The app matches every update to the subscription it is about. We found this while reading the code and haven't seen it happen in any store.
- For this, the app now also stores the subscription's ID at Shopify. The privacy policy lists it. The app still never sees payment details.
- The app's public start page no longer asks for your shop's address. It now says where you install and open the app: the Shopify App Store and the Shopify admin. Nothing has changed inside the app because of this.
- We noticed both on 2026-10-07 while checking the app against the Shopify App Store requirements.
BetaA committed response time, and the privacy policy now mentions backups
- Support now has a committed response time: we reply within one business day (Monday to Friday, German time); in an outage, on the same business day. On the Pro plan, "priority support" means a reply on the same business day. You'll find this on the "Contact and support" page and in the FAQ.
- The app's privacy policy now mentions backups. The app's database is backed up every night. Data the app deletes is kept in these backups for up to 14 more days and is then deleted there as well. The help article "Uninstalling and your data" and the FAQ say the same.
- Nothing has changed about the deletion itself: the app still deletes right away once Shopify asks it to after an uninstall.
- The app now tells the browser to only ever open it over an encrypted connection (HSTS). Until now it only redirected an unencrypted request.
- The Pro plan now also says in the app what "priority support" means: a reply on the same business day. You find it on the Plan page and in the feature list on the Overview page.
3
BetaThe activity log and the Overview page no longer jump while loading
- Fixed: when you opened the activity log, the table columns and the filter fields moved sideways once more while the page was building up. The columns now have their width from the start. "What happened" gets most of the space, and long sentences and long SKUs wrap within their column. The same goes for the two tables on the "Matching" page.
- Fixed: on the Overview page and on the "Locations" and "Sync" pages, the content first spanned the full width while loading and then moved together as soon as the side column appeared on the right. Its space is now kept free from the start.
- Fixed: in the settings, the focus outline of the "Real-time sync" card sat on the word "Status" on the left. It now keeps a distance from the text.
- We noticed the jump on 2026-10-07 while measuring in a test store.
BetaOne click from the privacy policy to the legal notice
- The app's privacy policy now has a link to the legal notice right below the introduction. Until now the legal notice was only at the end of the page, and you had to scroll all the way down to find it.
- Nothing has changed in the content of the privacy policy or the legal notice.
BetaSwitching real-time sync without a mouse, and its message now shows only once
- Fixed: after "Sync and turn on real-time sync", the page said twice that the sync before switching on is running. Once as a notice, and again right below it as a green message. Now it says so once, as a notice. The notice is still there after you reload the page for as long as the sync is running, and you can close it.
- Fixed: if you use the settings with a keyboard, the Tab key didn't take you to the checkbox and the button for turning real-time sync back on after "Turn off real-time sync". It jumped straight to the next card, and the only way back was Shift+Tab. Now the focus is on the card's status and message after every click in this card, and the Tab key takes you from there to the checkbox and then to the button.
- The messages of the "Real-time sync" card now appear above the checkbox and the button instead of below them. After turning it off, the message reads "Real-time sync turned off. Nothing is sent anymore."
- We noticed both on 2026-10-07 while going through the page without a mouse in a test store.
17
BetaWhen Shopify briefly slows requests down, real-time sync waits and tries again right away
- Shopify limits how many requests an app can send to a store in a short time. Once the limit is reached, Shopify turns a request away without carrying it out, and a moment later it works again. Real-time sync was meant to wait briefly in that case and repeat the same write. It didn't.
- Fixed: until now this counted as a failed transfer. The app tried again after a minute at the earliest, and for that time the Overview page showed the store as "can't be reached". Real-time sync now waits briefly and tries up to three times. Only if that still doesn't work does the app retry the transfer later, as before.
- Nothing changes for you in a sync: a change that was slowed down still shows as "Failed" in the activity log, and the next sync catches up on it.
- Fixed: if Shopify answers a write from a sync without saying whether anything was written, the change now shows as "Failed" in the activity log instead of "Written". We have never seen such an answer.
- We found the bug by reading the code and reproduced it in a test. We haven't seen it in any store.
BetaEarlier syncs show why they failed
- Fixed: under "Previous syncs", a failed run only said "failed". The app showed the reason for the latest sync only. Once another sync had run, there was no way to look it up. The reason is now shown right below the line of every earlier run.
- The same goes for a run the safety brake stopped: the line below says what triggered it.
- If the app doesn't know the cause, it also shows the technical message for support there. Long technical messages now wrap instead of running off a narrow screen. That also applies to "Last sync failed" at the top.
- The next step is still shown for the latest sync only, at the top of the page.
- We noticed this on a scheduled run from October 4, 2026 in a test store.
BetaUpdates from Shopify are no longer kept indefinitely
- The app saves every update from Shopify before processing it. Until now these updates stayed stored until the store's data was deleted after an uninstall. Now the app deletes a processed update seven days after it arrived.
- An inventory update that couldn't be processed after all retries stays under "Needs your attention" for 30 days. After that the app deletes it. Anything still out of step by then is brought back in line by the next sync.
- The app never deletes updates by age while they're still being processed. An uninstall or a deletion request that couldn't be processed also stays until it has been dealt with.
- On the Overview page, "Updates received from Shopify" now counts the last seven days. Until now it was everything since installation, so the number gets smaller.
BetaA failed scheduled sync runs again the same night
- Fixed: if a scheduled sync failed, there was no second attempt until the next scheduled time. With "Once a day", a hiccup of a few seconds meant no sync for 24 hours.
- If Shopify just couldn't be reached or slowed down requests, the app now tries again on its own: after 5 minutes, then after 30 minutes, then after 2 hours. After four attempts, it stops for this scheduled sync.
- The "Sync" page shows when the next attempt runs and which attempt it is, or that all attempts are used up. Every attempt stays listed under "Previous syncs", and a further attempt carries its number.
- The same applies when the app wanted to renew its access token for a store and Shopify didn't answer at that moment. That is how one group's midnight sync failed on 2026-10-04, and the next one only ran the following night.
- Not retried: anything that doesn't go away by itself, for example when Shopify has denied access to a store. Also not a sync the safety brake stopped, and not a sync you started manually.
- A further attempt never starts alongside a running sync. It is dropped if a sync has completed in the meantime, if the next scheduled sync is due, or if you change the schedule.
- Fixed: if a sync you started manually failed because Shopify couldn't be reached, the page said the app would try again on its own. It didn't. Now it says you can start it again.
BetaA store without access is now called what it is
- Fixed: when the app couldn't renew its access token for a store, the only cause shown was "[object Response]". That affected the "… can't be reached" notice, the log and "Needs your attention". It didn't say what to do. This happens when Shopify denies access to one of the group's stores, for example after an uninstall, or doesn't answer at the moment of renewal.
- Now it says what's going on. If Shopify denies access, you see "The app no longer has access to …" with the next step: open the store and the app there. If Shopify just couldn't be reached for a moment, it says so, and there's nothing for you to do.
- The same goes for a sync, a matching run and the "Locations" page when a store gives no access.
- Older entries with "[object Response]" now show a sentence too. For those, it wasn't recorded whether Shopify denied access or just couldn't be reached. The entry says so.
- The cause is in Shopify's library for apps and has been reported there.
Beta"Stores" only names the step that's actually next
- Fixed: under "What's next", the Stores page always asked you to connect locations as soon as the group had a second store. It said so even when locations, matching and real-time sync had long been set up.
- The page now names the next open step with the reason and a button: link locations, match variants or turn on real-time sync. It reads it from the same state as "Getting started" on the Overview page.
- Once all steps are done, the section disappears.
BetaThe deletion request doesn't hit a new installation
- 48 hours after an uninstall, Shopify asks the app to delete all of the store's data. Until now the app deleted without checking further. If you had reinstalled the app in the meantime and the request had still arrived, the new installation's access token, group and matches would have been gone.
- Before deleting, the app now asks Shopify whether it's currently installed in the store. If it is, the app deletes nothing and records the request as not carried out. If it isn't, the app deletes everything as before.
- If Shopify can't answer at that moment, the app doesn't delete on a guess and doesn't drop the request either. It asks again over the next twelve hours.
- Shopify's documentation doesn't say whether the request is still sent after a reinstall. We haven't seen the case in any store.
BetaOne changed inventory level no longer costs a sync the whole request
- The app sends the changes of a sync to Shopify in batches, up to 100 per store in one request. If one of those inventory levels had changed between reading and writing, Shopify rejected the whole request. The other levels then showed as "rejected" in the result too and only came through with the next sync. The app now sends them again in the same run, without the one that changed.
- The level that changed stays "rejected". That's intended: real-time sync transfers the change behind it, and the next sync evens out whatever is still apart.
- The app tries once per request. If another level changes at that very moment, the others wait for the next sync as before.
- Fixed: for a level that was only rejected along with the request, the activity log said "the inventory there changed in the meantime". That wasn't true, a different one had changed. The row now says that Shopify rejected the whole request.
BetaUninstall and deletion notices get through after a break
- Fixed: Shopify tells the app about every uninstall and, 48 hours later, asks it to delete the store's data. If the app had nothing to do with the store in the hour before, meaning no stock change came in from it and nothing was written to it, the app turned both notices away. The store then stayed marked as installed and its data wasn't deleted. The app now accepts these notices in every case.
- The same was true for the customer data requests Shopify sends to every app (access and deletion). The app doesn't store customer data. The requests are now always accepted and recorded.
- A stock change no longer gets lost either when the app can't renew its access token for the store at that moment.
- The cause is in Shopify's library for apps and has been reported there. We found the bug by reading the code and reproduced it in a test.
BetaA late uninstall notice no longer hits the new installation
- Fixed: Shopify tells the app about every uninstall. If that notice only arrived after you'd already reinstalled the app in the same store, the app took it for a new one. It deleted the new installation's access token and, the next time you opened the app, removed the group and matches. The app now goes by when Shopify triggered the uninstall and leaves the new installation alone.
- Good to know: in this case the group and matches from before the uninstall stay, and the store doesn't start from scratch (see "Uninstalling and your data").
- This happens when the notice doesn't reach the app right away, for example because the app couldn't be reached at that moment. We found the bug by reading the code. We haven't seen it in any store.
Beta"Installed" stays on the date of installation
- Fixed: on the Overview page, "Installed" didn't show the day you installed the app but the moment the app last signed in to Shopify again. That happens by itself, for example when you open the app after a break. The date now stays put. It only starts over when you uninstall the app and install it again.
- In stores where the date had already moved, the last time shown stays. The bug didn't affect syncing: the group, matches and real-time sync kept running.
- Fixed: if the app hadn't finished processing an uninstall when you reinstalled it in the same store, leftovers from the earlier installation stayed. The store now starts from scratch in that case too, as described under "Uninstalling and your data".
BetaThe brake against a second sync app catches more cases
- The app now also pauses real-time sync for a SKU when the same change comes back three times in the same store with no order behind it. Until now it had to arrive in two stores. That way the app also notices a second app that only transfers in one direction.
- In the test on October 6, 2026 the brake didn't pause because Shopify had merged two changes into one update. The app now reads such updates correctly (see "Real-time sync no longer passes its own changes back" further down). In a second test with a real second app the same day, the brake paused after the first round. By then, inventory was at 140 instead of 35 in both stores.
- The notice on the Overview page names the store where it happened and shows the quantity in every store.
- Good to know: the same amount four times within 15 minutes in the same store, with no order behind it, also pauses the SKU. Four returns of the same variant restocked one after another are one example. Up to three times doesn't trigger anything. After a pause, set the right quantities and resume the SKU.
- The app still can't prevent a loop like this, only limit it. Turn any other sync app off before you turn on real-time sync.
BetaReal-time sync doesn't turn on while another sync is running
- Fixed: if a sync was already running when you clicked "Sync and turn on real-time sync", for example the scheduled one, the app turned real-time sync on without waiting for its result. That was also the case when the safety brake stopped that sync afterwards. The app now declines and shows the reason below the button. Once the sync is done, click again.
BetaGroups stay separate
- "Try again" and "Process again" on the Overview page only work for items in your own group.
- If a transfer is no longer open, the app says so instead of reporting it as queued.
- Checked across every page of the app: a store only sees and changes its own group's data.
BetaReal-time sync no longer passes its own changes back
- Fixed: if real-time sync was running while a sync evened out quantities, it passed the sync's changes back to the other store. 20 and 17 became 23 and 20 instead of 20 and 20. This also affected the sync that runs when you turn on real-time sync.
- Fixed: if several orders came in for one store within a few seconds, the quantity there dropped too far.
- Fixed: if a quantity changed twice within the same second, the second change didn't reach the other store.
- Fixed: when the app caught up on changes for a store that had been unreachable for a while, it could pass one of them back to the store it came from.
- Fixed: if something sold while a sync was reading quantities, the sync could write that sale back in one store. A sync now leaves out SKUs whose quantity changes in the meantime and lists them in the result as "left out". The next sync includes them again.
- Fixed: if a transfer for a SKU was still pending because a store was briefly unreachable, a sync running in the meantime could write the sale back or subtract it a second time. A sync now leaves out those SKUs too until the transfer has caught up.
- Fixed: if something sold just before a sync read the quantities, and Shopify hadn't told the app about the sale yet, the sync wrote it back under "Highest inventory wins". Both stores then stayed one unit too high for good. While real-time sync is on, a sync now leaves out whatever changed in the last two minutes that the app hasn't been told about yet. This applies to manual syncs too.
BetaA brake for when a second sync app is writing too
- If the same change arrives a second time in two stores within 15 minutes with no order behind it, the app pauses real-time sync for that SKU. That's what it looks like when a second app syncs the same stores. All other SKUs keep running.
- The Overview page shows the pause with the quantity in each store, the transfers before it and a link to Shopify's adjustment history. That's also where you resume the SKU.
- If three SKUs are paused within 30 minutes, the app pauses real-time sync for the whole group.
- Syncs leave out paused SKUs and list them. Changes that weren't transferred during a pause are in the activity log with the result "Paused".
- Resuming paused real-time sync only works for stores in your own group.
- Fixed: an inventory update older than 24 days couldn't be processed.
- Added the same day: in a test with a second sync app, the brake didn't pause. Shopify had merged two changes into one update, and the app took it for its own. The brake is being reworked. Until then, the only protection is to turn the other app off before you turn on real-time sync.
BetaA question before real-time sync turns on
- Before turning on real-time sync, the app asks whether another app still syncs inventory between the same stores. It only turns on once you've confirmed that none is running. Two sync apps pass every change on twice and count your inventory down together.
2
BetaUp to date with Shopify's October 2026 release
- The app talks to Shopify through the latest interface (version 2026-10). Nothing changes for you.
- Redirects while signing in only lead into this app or your Shopify admin.
BetaNew name and privacy policy
- The app is now called "UM Multistore Sync", formerly "Multistore Inventory Sync". "UM" stands for UBARTAS.MEDIA, the developer.
- The privacy policy, including the legal notice, is publicly available in English and German.
- The app isn't in the Shopify App Store yet. Every entry here describes the beta.
2
BetaEnglish and plans by variant
- The whole interface is now also available in English. The app follows the language of your Shopify admin.
- Plans are now tiered by synced variants instead of by number of stores. There's a free plan, and every feature is included in every plan.
- One subscription covers the whole sync group.
- The Overview page shows the number of variants next to your plan's limit. From 80% it warns you in advance. Over the limit, real-time sync that is already on keeps running.
- Fixed: for privacy requests about customers that Shopify forwards, the app stored the email address and phone number along with them. It no longer does, and older entries have been cleaned up.
BetaActivity log, getting started and clearer messages
- New "Activity log" page: every transfer and every number set by a sync is listed as a sentence, with trigger, target, result and time. Filter by SKU, store, result and date range.
- One click on a SKU opens its full history in the activity log.
- A newly installed store gets "Getting started" on the Overview page, with the next step and the reason for it.
- Error messages name the cause and the next step in plain language, right where the error happened.
- All settings are in one place, on the "Settings" page.
- Notices can be dismissed and only come back when there's a new reason.
- If a problem lasts more than 30 minutes, the Overview page points it out.
- Fixed: the "Try again", "Process again" and "Checked, resume" buttons on the Overview page were disabled.
- Fixed: if real-time sync couldn't be turned on, the button seemed to do nothing. Now the reason shows up right away.
1
BetaReal-time sync, retries and self-healing
- Real-time sync: inventory changes move to the other stores in the group, two-way or one-way. Turning it on first runs a sync using your rule.
- Safety brake for real-time sync: if more than 20 inventory levels in one store drop to 0 within 10 minutes, the app pauses real-time sync for that store.
- Anything that doesn't go through is retried over twelve hours. Whatever is still open after that appears on the Overview page under "Needs your attention" and can be queued again.
- If the app was down for more than 15 minutes, it starts a sync on its own afterwards.
- If a sync finds changes that real-time sync missed, it catches them up and reports it on the Overview page.
- The Overview page shows the last transfer, today's transfers and errors, and the delay over the last hour.
- A group can have several location links. Each change stays within its link.
1
BetaReasons why nothing was synced
- A sync now tells you when stock sits at a location that isn't in any location link.
- It also tells you when inventory tracking is off for a SKU in a store, and how to fix it.
- Locations that can't be linked, because they're inactive or managed by another service, are now visible and marked with the reason.
1
BetaConnecting stores, matching and syncs
- Two stores can be connected into a sync group with an invite code.
- Matching uses the SKU to find which variants are the same across stores and gives the reason for every variant it can't match.
- A sync brings inventory in line using your rule, manually or on a schedule once or twice a day.
- A safety brake holds back changes that would drop inventory to 0 even though another store has stock.
- Every write is recorded with its old and new value.