Telemetry in the LS Retail Apps
This document explains, in plain terms, what diagnostic and usage data the LS Retail Omni Suite applications (LS AppShell, Mobile Inventory) can collect, where it goes, and how you control it. It does not require any technical background.
1. What telemetry is and why we collect it
4. Information attached to every telemetry item
7. Exceptions (errors and crashes)
1. What telemetry is and why we collect it
"Telemetry" here means three kinds of diagnostic signals sent to Azure Application Insights, Microsoft's monitoring service:
- Events — a record that something happened, such as a POS session starting.
- Performance metrics — timing measurements, such as how long a document took to send to the backend.
- Exceptions — details about an error or crash, so it can be investigated and fixed.
We use this data to understand how the apps are used, catch performance problems, and diagnose crashes. No other analytics service is used — telemetry only ever goes to Application Insights.
2. Two separate destinations
Telemetry from your app can go to up to two places, and they are governed by different rules:
| Destination | Who it's for | When it's sent |
|---|---|---|
| LS Retail's diagnostics resource | LS Retail's own support and engineering teams | Always, for every app installation, regardless of any setting below. This cannot be turned off. |
| Your own Application Insights resource | You, the customer, if you choose to connect one | Only if you have entered your own connection details and turned telemetry on (see Section 6). Even then, each data type (usage, performance, exceptions) has its own on/off switch. |
Both destinations, when active, receive the exact same information for a given event — there is no reduced or different version sent to one versus the other.
3. What is never collected
Regardless of your settings, the following are not included in any telemetry item:
- No user identity or staff ID
- No store ID or terminal ID
- No customer, transaction, or business data of any kind (item numbers, prices, receipts, etc.)
- No free-text or personally identifying content
Telemetry is limited to app usage patterns, timing measurements, technical error details, and the general device/app information described in the next section.
4. Information attached to every telemetry item
A small set of technical, non-personal details is automatically attached to every event, metric, and exception. If you look at this data in Application Insights, you'll see it under these field names:
| Field name in Application Insights | Information | Example |
|---|---|---|
LSC LS Application
|
Which app sent it | e.g. "AppShell", "MobileInventory" |
LSC App Name
|
App name | app package name |
LSC App Version
|
App version | version number |
LSC OS
|
Operating system | Windows, Android, or iOS |
LSC OS Version
|
Operating system version | e.g. build/version string |
LSC Machine Name
|
Device name | the device's own name |
LSC Device Manufacturer
|
Device manufacturer | e.g. "Zebra" |
LSC Device Model
|
Device model | e.g. "TC52" |
LSC Device ID
|
Anonymous device identifier | a one-way (irreversible) scrambled value, so the same device can be recognized across sessions without revealing anything about it — Windows only, not sent from Android or iOS |
None of these values can be used on their own to identify a specific person, and no such identification is attempted.
5. Usage events
An "event" is logged the moment a specific, predefined action happens in the app. Today, two such actions are tracked:
| App | Event name | What is tracked | When it fires |
|---|---|---|---|
| LS AppShell (Windows, iOS, Android) | LSC AppShell POSStarted
|
A POS/config session was started | Whenever a user opens a configuration, and also automatically at app launch for any configuration set to start automatically |
| Mobile Inventory (Android) | LSC MINV MenuActionItemSelected
|
A menu action was opened | Whenever a user opens an item from the app's action menu |
Additional technical detail (Application Insights field names) recorded alongside the LSC AppShell POSStarted event, on Windows only:
| Field name | Records | Possible values |
|---|---|---|
LSC Run Type
|
Whether the session was started manually by the user or launched automatically at startup | Manual, Automatic |
LSC Browser Type
|
Which browser engine is actually rendering the session — this reflects what's really running, which can occasionally differ from what's configured, e.g. if a specific browser was forced via a startup option | Internal, Chrome, Edge |
LSC Config Type
|
What type of configuration was opened | the configuration type |
On mobile (iOS/Android), the same LSC AppShell POSStarted event instead carries LSC Printer and LSC Payment, recording which printer and payment type are configured.
For Mobile Inventory's LSC MINV MenuActionItemSelected event, the field LSC Menu Action Item records the specific action that was opened (e.g. which type of task list).
Note: the "session started" event reflects that a start was attempted, not that it necessarily completed successfully — for example, it is recorded even if the user then cancels the sign-in prompt, or the configuration turns out to be offline. In rare cases (retrying a backup configuration) it can be recorded twice for a single user action.
6. Performance metrics
Performance metrics are only currently collected in Mobile Inventory, and only measure the round-trip time of network calls to your backend:
| Metric name | What is measured |
|---|---|
LSC MINV WorksheetSend
|
Time to send an inventory worksheet or transaction |
LSC MINV DocumentSend
|
Time to send a document |
LSC MINV ItemLookup
|
Time to look up an item |
All three are measured in milliseconds. Each measurement also carries the field LSC Connector, which records which backend it was measured against, so slow calls can be traced to the right system:
LSC Connector value |
Backend |
|---|---|
SaaS Connector
|
Business Central |
Commerce Service Connector
|
OmniService |
Timing is recorded whether the call succeeds or fails, so a spike in slow "failed" calls is just as visible as slow successful ones.
7. Exceptions (errors and crashes)
When something goes wrong, the app can record the technical error details (type of error, message, and the internal call sequence that led to it) so it can be diagnosed. As with everything else, no business or customer data is included — only the technical error information.
Every recorded error is also tagged with a field named LSC Is Handled, set to one of:
LSC Is Handled value |
Meaning |
|---|---|
true
|
Handled — the app caught the problem itself, logged it, and kept running normally (the user may have seen a message, but the app didn't crash). |
false
|
Unhandled — the problem reached the app's last line of defense, meaning the app most likely crashed or is about to close. |
This distinction lets support teams immediately separate "the app is objectively crashing" from "something went wrong but was contained."
8. Settings you control
Each app that supports telemetry exposes these settings, typically under its diagnostics/telemetry section:
| Setting | What it controls |
|---|---|
| Enabled | Master switch for sending any telemetry to your own Application Insights resource. When off, nothing is sent to your resource — but LS Retail's own diagnostics resource is unaffected either way. |
| Connection string | Where your own Application Insights resource is. Required for the above to have any effect. |
| Send usage data | Whether usage events (Section 5) reach your resource. |
| Send exception data | Whether error/crash details (Section 7) reach your resource. |
| Send performance data | Whether performance metrics (Section 6) reach your resource. Only available in Mobile Inventory today. |
Changing these settings takes effect the next time telemetry reconfigures, which happens automatically when you save your settings. If you export or share a diagnostic log file, your own connection string is automatically removed from it first.