---
title: "Managing data in NewStore"
slug: "managing-data-in-newstore"
description: "Explore NewStore's data consumption methods, including Omnichannel Insights, operational reports, and APIs, to enhance your business performance."
tags: ["data", "reports", "data model", "insights", "explore", "sales", "reporting", "liveboard", "ThoughtSpot", "event stream ", "graphql"]
updated: 2026-08-18T12:44:32Z
published: 2026-08-18T12:44:32Z
canonical: "docs.newstore.com/managing-data-in-newstore"
stale: true
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.newstore.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing data in NewStore

NewStore has several methods that you can use to consume data from the platform. This document gives guidance and best practices on which services and features to use for your business needs.

Data is typically consumed for one of these purposes:

1. **Track business trends** and analyze performance, using Omnichannel Insights
2. **See the current status and act on it**, using operational reports
3. **Give store teams visibility of their own performance**, using the Associate App Sales Dashboard
4. **Exchange data with third-party systems**, using application programming interfaces (APIs), the Event Stream, and GraphQL

The sections below cover each of these, grouped by who uses them:

- Headquarters (call center, operations, retail teams, some store managers, and executives): Omnichannel Insights, operational reports
- Stores (store managers, store associates): Associate App Sales Dashboard
- Service integrators and developers: APIs, the Event Stream, GraphQL
- Everyone: data retention

## Reporting needs for headquarters

Headquarters has two options, and they answer different questions:

- Omnichannel Insights answers *what is the trend?* It is analytical and historical, and covers a rolling 15-month window.
- Operational reporting answers *what is the current status, and what do I do about it?* It shows the latest state and is where you take action.

### Omnichannel Insights

[Omnichannel Insights](/v1/docs/managing-omnichannel-insights) brings all your retailer data into a business intelligence tool embedded in Omnichannel Manager. Use it to understand trends, assess the state of the business, and adjust your strategy based on what the data shows.

Insights appears in Omnichannel Manager under the **Insights** menu, which has two items: **Explore** and **Reports**.

- **Explore** allows data creators to:
  - Search the data directly
  - Build dashboards for other users
  - Share those dashboards with others in the organization, either directly in Omnichannel Manager or via email
- **Reports** allows data consumers to track and improve a specific metric.

Typically, an Explore user designs a report for a Reports user.

Insights covers a rolling 15-month window of data. Analysis reaching further back than 15 months is not possible in Insights. See [Data retention](/v1/docs/managing-data-in-newstore#data-retention).

#### Example: Understand trends in store fulfillment performance

Operations, data teams, and retail teams can use **Insights → Explore → Template → Fulfillment** to get a quick view of store rejection rates. For that, you can filter the report by one or more fulfillment locations. Optionally, make a copy of the template and adjust the report as desired.

#### Example: Track fill rate by stores to understand underperforming locations

A retail manager or store operations manager might want to adjust the number of fulfillments a given store can handle. To understand which stores have a higher fill rate (number of fulfillments completed compared to the number rejected), use **Insights → Explore** to compare **Fill Rate** across locations, and across how many associates are available to fulfill. This can provide an optimal number of fulfillments relative to the number of available fulfillment employees, which you can then adjust in **Routing → Locations** in Omnichannel Manager.

#### Example: Track email capture percentage by sale location

There might be a push for more email capture during store sales. This requires a metric to measure, a baseline of current capture rate, actions to take to improve the capture rate, and measurement to determine if the actions turned into a higher capture rate. You can do this from Omnichannel Insights by using the default Customer dashboard, or by creating a custom dashboard to track capture rate by location. Then perform the actions desired to improve the capture rate, and view the dashboard again to understand the impact.

### Operational reporting

Operational reports allow you to understand the current status of events and act on them. They contain the latest information available to NewStore about omnichannel, point of sale (POS), and order management system (OMS) events, and they appear throughout Omnichannel Manager.

An operational report is available in one of two forms, depending on the report:

- As a table displayed in Omnichannel Manager
- As an export, which is the same report as a downloadable file rather than an on-screen view

Both draw on the same underlying data, so an export contains what the corresponding table shows.

Examples include the **Sales → Orders** table, or the **Store Operations → Stock on Hand** report.

#### Example: Track and process orders that are on hold

A call center representative might need to reach out to shoppers to ask what they want to do with an order that can only be partially fulfilled, or an Operations member might want to cancel all orders that are on hold due to an inventory availability issue. You do this from the **On Hold Orders** page in Omnichannel Manager. All orders that are placed on hold, and might require user action, appear in **Sales → On Hold Orders**.

#### Example: Track stock on hand for a specific store location

An Operations member might want to understand what NewStore believes is available in a given store, to place an order for more merchandise based on what is available in the store. You do this from **Store Operations → Stock on Hand** in Omnichannel Manager: select a store, a stock location, and an on-hand threshold.

## Reporting needs for stores

### Understand sales performance

The [Associate App Sales Dashboard](/v1/docs/using-newstore-associate-app-for-sales-metrics) helps store employees understand their own performance and their store's performance. The dashboard displays what is occurring in the store for the current day. Where it is enabled, users access it from **More → Sales Dashboard**.

Integrators or administrators enable the Sales Dashboard in **Associate App → Customizations**, then inform sales associates and store managers where to find it. Optionally, enable it in the staging environment to test and validate the data before enabling it in production for associates.

## Retrieving data as integrators and developers

NewStore provides three mechanisms for retrieving data programmatically. They are not interchangeable.

APIs are the source of truth. The Event Stream and GraphQL are secondary sources derived from platform activity, and neither is authoritative. When the data must be correct and current, use an API.

| Mechanism | Use it for | Do not use it for | Source of truth | Data available |
| --- | --- | --- | --- | --- |
| **APIs** | Authoritative reads and writes, platform configuration, enriching an event with trusted data | Bulk historical extracts | Yes | Active transactional data. See [Data retention](/v1/docs/managing-data-in-newstore#data-retention) |
| **Event Stream** | Reacting to platform activity in near real time; feeding an enterprise resource planning (ERP) system, business intelligence (BI) platform, or backup solution | Reporting, or as an all-in-one disaster recovery tool | No | Rolling 60 days |
| **GraphQL** | Enriching a received event with context when no API covers it | Reporting, scraping, or lookups | No | Rolling 60 days |

### APIs

[APIs](https://docs.newstore.net/api/) allow two applications to talk to each other. For example, NewStore can inform an ERP system that inventory has moved from location A to location B. Because a feature takes less effort to deliver in an API than in the user interface, some configuration is available via API before it reaches Omnichannel Manager.

NewStore provides two categories:

- **Integration APIs** let NewStore communicate with your retail ecosystem of partners.
- **Configuration APIs** perform system-level setup, such as setting up a catalog. These sometimes offer the same functionality as Omnichannel Manager, for example the routing setup.

NewStore is migrating to a more modern generation of APIs via the [Omnichannel API Explorer](https://developer.newstore.com/#/http/getting-started/quickstart), which better documents the purpose, data models, and design of existing and new APIs. The Omnichannel API Explorer does not cover every API, so check both references.

### Event Stream

The Event Stream provides a best-effort stream of events for actions that occur on the platform. Service integrators create streams of events based on a topic, such as `refund_request.issued` or `inventory_count.items_counted`.

Consuming the Event Stream correctly requires three things:

- **Assume at-least-once delivery.** The platform can replay [events](https://docs.newstore.net/api/webhooks/stream_webhook_sink_hook/) to ensure it eventually sends them all, so the same event can arrive more than once. Your integration needs middleware that handles duplicates.
- **Allow for publishing delay.** NewStore usually publishes an event within seconds of the change, but publishing can take up to 15 minutes.
- **Treat events as a trigger, not as truth.** An event tells you something happened. Where you need the authoritative state, follow up with an API call.

Retention is a rolling 60 days. That window exists to absorb downstream failures and lag, giving you time to recover your systems. It is not a data store: consume events in real time rather than relying on the window in normal operation.

Typical Event Stream use cases:

- Streaming events from NewStore to your ERP system
- Streaming events from NewStore to your BI platform
- Streaming events from NewStore to your backup or disaster recovery solution
- Creating a temporary integration to recover data from an outage, where the data is not older than 60 days

Do not use the Event Stream for:

- Reporting, or any query spanning more than 60 days
- An all-in-one disaster recovery tool

### GraphQL

GraphQL takes the Event Stream and temporarily stores the data so it can be retrieved on request. It exists to supplement a received event with additional information a third-party system needs.

Like the Event Stream, GraphQL is a secondary source and is not a source of truth. It is eventually consistent, so data appears there later than in the originating system. Assume its data lifetime is coupled to Event Stream retention. Prefer an API over the generic GraphQL interface wherever one exists.

Typical GraphQL use case:

- Enriching an Event Stream event with additional data, such as adding order information to a shipping event. For example, looking up order data when the Event Stream emits a `payment_account.amount_refunded` event.

Do not use GraphQL for:

- Scraping a non-specific set of Event Stream data, such as looking up all refunds for the past six months
- Generating reports
- Querying as a lookup table, for example looking up an order ID by item code or stock keeping unit (SKU)

#### Example: Send data to an ERP system from NewStore

Create an Event Stream integration in NewStore and subscribe to that stream from the ERP system. This ensures the ERP system is aware of all POS activity on the platform.

When you need further context, such as additional payment data on receiving an order event, call a RESTful API rather than GraphQL, because APIs are the source of truth. Use GraphQL only where no API covers the data, and account for its eventual consistency: there is a delay between the change in the source system and its appearance in GraphQL.

## Data retention

How long data remains available depends on which service you retrieve it from. Each service has its own retention policy, and they are independent of one another.

| Data source | Retention | Notes |
| --- | --- | --- |
| **Transactional systems** (APIs, operational reports and exports) | Records created from 2018 onward | Records created before 2018 are archived and no longer returned. See [Archived transactional data](/v1/docs/managing-data-in-newstore#archived-transactional-data) |
| **Event Stream** | Rolling 60 days | The window exists for recovery, not storage. See [Event Stream](/v1/docs/managing-data-in-newstore#event-stream) |
| **GraphQL** | Rolling 60 days | Data lifetime is coupled to Event Stream retention. See [GraphQL](/v1/docs/managing-data-in-newstore#graphql) |
| **Insights and analytics data** | Rolling 15 months | Data older than 15 months is not available for analysis or reporting. See [Omnichannel Insights](/v1/docs/managing-omnichannel-insights) |

The transactional archiving policy does not override or change the retention policies of the other services.

### Archived transactional data

Transactional data created before 2018 has moved out of active transactional systems into an archived storage layer. This keeps active datasets smaller, which helps core systems stay responsive and reliable.

Archived transactional data is:

- Retained and not deleted
- Securely stored for compliance and historical purposes, in line with applicable legal and regulatory requirements
- Removed from active operational datasets

NewStore applies this approach consistently across all tenants and environments.

> [!NOTE]
> **Archived data cannot be reached through standard channels**
> 
> Pre-2018 transactional records are not returned by:
> 
> - Standard transactional APIs, for example Orders, Payments, or Cart
> - Operational user interfaces that rely on those APIs
> - [Operational reports and exports](/v1/docs/managing-data-in-newstore#operational-reporting), which read from active transactional sources
> 
> To obtain archived records, [request them from support](/v1/docs/managing-data-in-newstore#request-archived-data).

Because these channels all read from the same active data, the effect is consistent across them. If the Orders API does not return a pre-2018 order, that order does not appear in the related operational views, tables, or exports either.

### Request archived data

If you need access to pre-2018 transactional records, raise a retrieval request through [NewStore Support](https://help.newstore.com).

Include the following in your ticket:

- Tenant or business identifier
- Relevant time range
- Required data type, for example orders or payments data

NewStore handles requests through the standard support process. Fulfillment depends on feasibility and on the applicable retention policies.

## Related

- [Managing data in NewStore](/managing-data-in-newstore-3.md)
- [Managing data in NewStore](/managing-data-in-newstore-2.md)
- [Managing data in NewStore](/managing-data-in-newstore-1.md)