Plan requirement
| Subscription | Any plan |
| Access | Agent |
A report says one thing and a view says another. Six causes, and all six are the report being right about a different question.
Why do my report and my view not agree?
- A dashboard count differs from a view count.
- Two reports on the same subject disagree.
- A number changed without anybody changing the report.
One: the refresh cycle
The view is current; the report is as of the last refresh. Check the timestamp on the dashboard before anything else, because this explains a large share of these.
How stale that can be depends on your plan. On Suite Team, Suite Growth and Explore Lite the data syncs once a day, at midnight in the account's time zone. On Suite Professional and above, and on Explore Professional and above, a sync starts an hour after the last one finished, at a randomised moment within that hour, and a large account can take more than two hours to finish one.
There is a trap underneath that. If nobody runs a report or dashboard for more than 30 days, the refresh drops to weekly on its own. Opening one, or scheduling an email delivery, puts it back. So the account that comes back to reporting after a quiet quarter sees week-old numbers and concludes the reporting is broken.
Two: the time zone
Explore reports in the time zone on each reader's own profile rather than the account's, so the same report can give two colleagues different numbers. Around midnight, "yesterday" means different things, and month boundaries shift a day's worth of tickets.
Three: business hours against calendar hours
A first reply time of four hours in calendar terms is one hour in business terms. Both are correct, and a dashboard mixing them cannot be reconciled by anybody.
Four: the filters are not the same
A view showing "open tickets" usually excludes some group, brand or form without saying so prominently. Read the view's conditions and the report's filters side by side; they are rarely identical.
Five: counting events, not tickets
A ticket solved, reopened and solved again is one ticket and two solves. Reports counting solves legitimately exceed the number of tickets, and this surprises people every time.
Six: the organisation moved, not the tickets
Grouping by Requester organization name uses the requester's current default organisation, so a customer who moved between organisations takes their whole ticket history with them. Last quarter's figure changes without a single ticket changing.
Ticket organization name is the organisation on the ticket itself and stays put. If a historical number moved and nobody edited anything, check which of the two the report uses.
The rule underneath the last three
Explore reports the current state of your ticket history rather than a snapshot of it. Update, merge or delete a ticket and every figure computed over that history changes with it, including figures for periods already closed. So last month's screenshot is not a baseline you can check today's report against, and a number that moved does not mean somebody edited the report.
Two mechanisms do this quietly. A merged ticket is closed and its conversation moves, so the two are no longer separate conversations in the counting. And a deleted ticket leaves the Tickets dataset altogether, so the same report run after a deletion legitimately returns less.
How to settle it
Take one specific ticket that you believe should be counted, and check whether it appears in each. Arguing about totals goes nowhere; a single ticket exposes the difference immediately.
Then write the definition down
Once you know which is right for the question, put the definition on the dashboard. This argument recurs otherwise, with the same two people.
Comments
0 comments
Article is closed for comments.