# StoreConnect Support

StoreConnect POS runs entirely in the browser and uses browser storage technologies to maintain a local copy of your organization's data on each device. This enables fast, responsive operation even under varying network conditions.

## Storage architecture

### IndexedDB

POS stores all product, customer, order, and inventory data in IndexedDB — a built-in browser database designed for large volumes of structured data. Key points:

- IndexedDB is persistent browser storage — it survives page refreshes, browser restarts, and standard cache clears.
- It is a standardized web technology supported by all modern browsers.
- Storage size varies by device and the size of your catalog and transaction history — it can reach several hundred megabytes to over a gigabyte on large datasets.

:::warning
IndexedDB is not cleared by a standard cache reload (Ctrl+Shift+R / Cmd+Shift+R). Only using the browser's **"Clear All Site Data"** or **"Clear Storage"** developer tools option will wipe it.
:::

### Local Storage

The POS keeps a small amount of information in the browser's Local Storage so it doesn't have to start from scratch every time it opens. This includes:

- The secure key that lets the register identify itself to StoreConnect (so it stays connected without signing in again each time).
- A saved snapshot of what the POS was doing, so it can pick up where it left off when the page reloads.

Once the POS is up and running, this stored information is only used to get started — the POS doesn't keep saving live sales data there as you work.

### Storage comparison

| Storage | Purpose | Survives cache clear? | Survives "Clear All Site Data"? |
|---------|---------|----------------------|---------------------------------|
| IndexedDB | Product, customer, order data | Yes | No |
| Local Storage | Auth token, session state | No | No |

## What happens when Local Storage is cleared

If Local Storage is cleared (for example, via a cache reload or browser setting):

1. The API token is removed, disconnecting the register.
2. POS detects the missing token and automatically redirects to the login screen — this is a handled transition, not an error state.
3. The user is prompted to re-login and re-register the device.
4. IndexedDB data is preserved — products, customers, and orders remain intact.
5. Once logged back in, POS reconnects to the existing IndexedDB database. A full re-sync is not required.
6. The POS syncs to catch up on anything that changed while it was offline, updating only what's new rather than reloading everything.

## Sync process

### Initial sync

When a device is set up for the first time (or after a full data wipe), POS performs an initial sync that downloads all records from the server:

- Records are downloaded in chunks via standard web requests. The network load is minimal.
- Most sync time is spent writing records to IndexedDB, not downloading them. Performance is primarily limited by device hardware.
- Newer, faster devices typically complete the initial sync faster; older or lower-powered devices may take significantly longer — this is a hardware limitation, not a network or application issue.
- Records are synced in oldest-created-first order. This means recently created records (such as today's orders) will be available last. During initial sync, some records may not be immediately available for lookup.

### Keeping up to date

After the first full sync, the POS keeps itself current by only downloading what's new:

- It downloads only the records that have changed since the last update, not everything.
- These updates happen automatically in the background and are quick.
- This keeps each device up to date without having to re-download the entire catalog every time.

## Day-to-day best practices

### Avoid wiping data unless necessary

Clearing IndexedDB data should be a last resort. A full wipe means the device must repeat the initial sync, which:

- Takes significant time (up to an hour or more, depending on hardware).
- Puts the device under load while syncing.
- Means some records won't be available for immediate lookup until the sync catches up.

### Handling authentication issues

Before wiping any data:

1. Try a simple page refresh first.
2. If the register is disconnected, [re-login and re-register the device](pos-connect-a-register). IndexedDB data is preserved and POS resumes with a quick delta sync.
3. Use the **Disconnect Only** button (where available) to disconnect and reconnect a register without a data wipe. See [Disconnect a POS register](pos-disconnecting-a-register).
4. POS data is self-healing — in most cases, simply reconnecting the register resolves the issue.

### When a data wipe may be necessary

A full data wipe is only warranted if:

- There has been a significant reconfiguration of the database schema (for example, changes to index configuration in POS Layout Fields).
- POS is experiencing persistent errors that cannot be resolved by reconnecting.
- StoreConnect Support has specifically advised a data wipe.

If the POS is unresponsive and reconnecting does not resolve the issue, see [Reset an unresponsive POS](reset-an-unresponsive-pos) for step-by-step recovery options before considering a data wipe.

## StoreConnect upgrades

### How upgrades work

StoreConnect is a cloud application — upgrades are org-wide and apply to all devices simultaneously. POS picks up application updates on page refresh. Devices do not need to be individually updated.

Occasionally, an upgrade may include database schema changes (for example, new fields or new indexes).

### Schema changes during upgrades

When POS detects a schema change after a page refresh:

1. POS displays an "Initializing" spinner while it applies the database changes.
2. POS is inaccessible during this time. Users cannot process transactions until the migration completes.
3. Duration depends on the size of the schema changes — minor additions are quick, larger restructures take longer.

### Upgrade best practices

- Always test upgrades in a sandbox environment first before rolling out to live store devices. This lets you gauge the impact of any schema changes and estimate downtime.
- Schedule upgrades during off-peak hours when possible, to minimize disruption if schema migrations are required.
- StoreConnect changes are generally additive — new fields and indexes are added rather than existing ones removed or altered. Destructive schema changes are extremely rare and will be communicated in advance.
- After an upgrade, monitor a few devices to confirm they have successfully applied the changes before resuming normal operations across all registers.

## Debugging POS devices

### Browser-based POS (desktop/web)

If the "Initializing" spinner is taking excessively long or POS appears stuck:

1. Open the browser's **Developer Tools** (F12, or right-click and select **Inspect**).
2. Navigate to the **Console** tab.
3. Look for any red error messages. If there are no errors, the process is likely still running normally — it may just be taking longer due to data volume or device hardware.
4. Common console messages during sync include progress updates for record inserts. These are normal.
5. If you see repeated authentication errors or network failures, check the device's internet connection and try refreshing the page.

### POS native application (Android/iOS)

1. Tap the **three dots (...)** in the bottom right-hand corner of the screen.
2. Select **Show Logs** from the menu.
3. Enter the register PIN code for this register.

:::note
This is the PIN you set for the register when adding it to the Android app — not the day-to-day user PIN that staff enter when signing in to a shift. The Android app supports multiple registers, each with its own PIN to control access.
:::

4. Review the log output for errors. If there are no obvious errors, the process is likely still running and just needs more time.

### Log patterns

| Log pattern | Meaning |
|-------------|---------|
| No errors, sync messages visible | Sync is running normally — wait for it to complete. |
| Authentication errors | Session may have expired. Try re-login. |
| Network/fetch errors | Check internet connectivity. |
| Quota exceeded errors | Device storage is full. Free up space or contact StoreConnect Support. |
| Repeated errors for the same object | Possible data issue. Contact StoreConnect Support with the error details. |

## Troubleshooting quick reference

| Symptom | Likely cause | Resolution |
|---------|-------------|------------|
| POS shows login screen unexpectedly | Local Storage cleared or session expired | Re-login. IndexedDB data is intact — no data wipe needed. |
| "Initializing" spinner on load | Schema migration in progress after an upgrade | Wait for it to complete. Do not refresh or close the browser. Check logs if it persists. |
| Missing recent records | Sync processes oldest-created records first | Allow time for the sync to work through the backlog. Recent records will appear as the sync catches up. |
| Missing older records after re-login | Delta sync in progress | Records will populate progressively. Give it time. |
| POS is slow or unresponsive during sync | Initial sync or large delta sync in progress | Allow the sync to complete. Avoid running other heavy applications on the device during sync. |
| Persistent errors after reconnecting | Possible data corruption or schema mismatch | Contact StoreConnect Support. A data wipe may be advised as a last resort. |

## Device and environment recommendations

- Use modern hardware. Sync performance is heavily influenced by device CPU and storage speed. See [Compatible hardware for POS](compatible-hardware-for-pos) for recommended devices.
- Use a supported, up-to-date browser. POS relies on modern browser APIs. Keep the browser updated to the latest stable version.
- Maintain a stable network connection. While POS is resilient to intermittent connectivity, a stable connection ensures delta syncs stay current.
- Avoid clearing site data routinely. There is no benefit to periodically clearing browser data for POS — it will only trigger unnecessary re-syncs.
- Avoid browser extensions that aggressively manage storage. Some privacy or performance extensions may interfere with IndexedDB or Local Storage. Whitelist the POS URL if necessary.
- Keep the POS tab active during initial sync. Browsers may throttle background tabs, which can slow down the database build process.
- Bookmark the POS URL. A bookmarked URL ensures consistency and avoids navigating to incorrect addresses.

---

## Follow StoreConnect

- [Email Newsletter](https://getstoreconnect.com/c/lp-newsletter)
- [LinkedIn Newsletter](https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7444956928444862464)
- [YouTube](https://www.youtube.com/channel/UCngKdP2x8l1wcbAKW3tvU8g)
- [LinkedIn](https://www.linkedin.com/company/storeconnect)
- [X / Twitter](https://x.com/storeconnecthq)

## Popular Links

- [Partners](https://getstoreconnect.com/partners)
- [News](https://getstoreconnect.com/articles/news)
- [Events](https://getstoreconnect.com/articles/events)
- [Feature Comparison](https://getstoreconnect.com/how-we-compare)
- [Download a free trial](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FMkeKUAT)
- [Book a Demo](https://getstoreconnect.com/contact)

## Documentation

- [Help documentation](https://support.storeconnect.com/help-documentation)
- [Videos & tutorials](https://support.storeconnect.com/videos-tutorials)
- [Developer reference](https://support.storeconnect.com/developer-reference)
- [Release notes](https://support.storeconnect.com/release-notes)
- [Troubleshooting](https://support.storeconnect.com/troubleshooting)
- [Trust Center](https://trust.getstoreconnect.com/)
- [Status Page](https://status.storeconnect.com/)

## Contact

- info@getstoreconnect.com
- US +1 415 745 3230
- AUS +61 2 8365 2308

100 S Ashley Dr, Suite 600-2461
Tampa FL 33602-600 USA

Level 22, Sydney Place
180 George Street
Sydney, NSW, 2000, AUS

---

StoreConnect Support — https://support.storeconnect.com