Table of Contents
What do I do if I notice a discrepancy?
You may notice on some reports that there is a note about how recently your data was updated. If you’re confused by what it means, don’t worry! Assembled caches certain data so that we can load your reports quickly. In this article, we’ll walk you through what data and reports we cache and how often we refresh your data.
What does cached mean?
Instead of computing the report when it loads in your browser, we compute the data at fixed intervals. That allows us to display the reports using pre-computed data making the report load without needing to wait.
What data does Assembled cache?
Our application caches two sets of data: contact stats and agent metrics.
Contact stats are non-agent specific and ticket-related. Metrics such as solves from all agents, average handle time across all agents, and reopens would be contact stats. Specific agent metrics are not included.
Agent metrics are event and agent state specific. Here’s a full list of the metrics that this encompasses:
Actual seconds in adherence
Total adherence actuals
Productive seconds worked
All seconds worked
Non productive seconds worked
What reports utilize cached metrics?
The following reporting use cached contact stats:
- Staffing timeline’s New cases and Reopened cases (when filtered by channel)
- Forecasted vs actual
- Forecast→Management's actuals
The following reports use cached agent metrics:
- Team performance
- Agent scorecard
- Only the agent trends section older than the current day uses cached metrics. The adherence timeline is not using cached metrics.
Assembled does have two reports that will not be using cached metrics: Queue config and Realtime dashboard. These reports are constantly changing in real-time, and Assembled will continue to pull in those live changes for you.
How often is data recomputed?
Regularly scheduled recomputes
Daily data- such as incoming contacts- is recalculated on at regular intervals throughout the day.
Reports that are cached will have a note sharing when the last computations ran. Depending on how far back you are looking, data could have been recomputed several days ago. Typically, your older data will not see many updates. Locking that data in will ensure consistency when looking at those reports in the future
The other way data is recomputed is by triggers. We treat changes to queue mappings or integration backfills as triggers to adjust the data. When we detect one of these triggers, we run a backfill to adjust the data accordingly in order to make sure we provide correct data.
We do have data that is considered immutable- it doesn’t up update or be re-computed. The data we consider immutable is agent data that is 7+ days in the past. Any data more than seven days ago, is not going to be recomputed automatically or with a trigger. The assembled application will use cached metrics data even if its under 7 days old, but the metrics will continue to be updated as data changes until it is past the 7 day mark.
Data within the seven day range will be recomputed with our data jobs, and if any adjustments are made to result in a trigger.
You can reach out to Support to request agent data to be backfilled if you make an adjustment that needs to run on historical data. However, note that a backfill is all or nothing. If you want to preserve queue history, but then make an agent state mapping change that you want to apply retroactively, you can’t run the backfill and preserve the old queues. All the changes will be used when recalculating.
What do I do if I notice a discrepancy?
If you notice an issue with ticket data, the first place to check is the Queue config page. There we can see how many tickets have synced over from your contact platform integration and these numbers are not cached. You can search by queue, channel, and time frame using our audit panel.
If you see a difference in numbers that you don’t expect, feel free to reach out to email@example.com with details on what you see.