Reports - End-user status attribute is misleading for suspended or deleted end-users



Posted Feb 12, 2025

I have been building reports trying to discover where phantom calls are logged - these would be calls in which suspended users leave voicemail (but apparently the voicemail isn't recorded).

 

When I look at a report for calls in 2021 for example, I see results for several end-users who are currently suspended but at the time of the call, were active.

 

It contradicts what I have been told by Zendesk support agents - in that a suspended user is prompted to leave voicemail, however no voicemail is recorded.

 

 

How can this be a Voicemail call from a Suspended end-user?

 

From Metrics and attributes for Zendesk Talk – Zendesk help:

 

End-user status - The status in Zendesk Support of the end user associated with the call.

 

Is the intent of the report to show the End-user current status or the status at the time of the call?

 

I almost suspect the answer is “neither” because I have experimented with suspending and unsuspending users and reloading the report, and the status shown in the report does not change.

 

 


0

1

1 comment

Hi Matthew,
 
Thanks for sharing the details and for highlighting this — great investigative work!
 
To answer your question: In Zendesk Explore, the "End-user status" field reflects the user’s current status at the time the report is generated, not their status at the time of the call. This explains why you are seeing some inconsistencies, like a voicemail from a user who is now suspended even though they may have been active when the call originally occurred.
 
Unfortunately, the historical status (i.e., what the status was at the exact time of the call) is not tracked natively in Explore datasets. As a result, even if you suspend or reactivate users after the call event, the report will always display their most up-to-date status when you refresh or rerun the report.
 
This behavior aligns with what you've observed during your testing (suspending/unsuspending users without changes appearing in the historical data). It’s a known limitation, especially when trying to audit activities over time based on dynamic user attributes.
 
If you are trying to get a more accurate picture of the user’s activity at the time of the call, you might need to rely on call-specific timestamps and cross-reference them manually with historical user records — or consider capturing snapshots via triggers or automations at the time of ticket creation.
 
Hope this clarifies things a bit! Let me know if you'd like me to suggest a potential workaround depending on what you need this report for.

0


Sign in to leave a comment.

Didn't find what you're looking for?

New post