Recent searches


No recent searches

Explore User Group Filtering

Not Planned


Posted Jul 16, 2019

It's seems that in explore (same as in insights) we still don't have the ability to filter based on a users group.  I know we can filter based on ticket group, but I'm looking more at a group of users rather than what type of ticket they are looking at. Currently all we can do is add each user 1 by 1 to a filter of a report, multiply that by however many reports you have and by however many groups you have, thats in INCREDIBLY time consuming process. 

We need to be able to filter by user group in examples like...

  1. Updater is a member of "XYZ" Group.
  2. Assignee is a member of "XYZ" Group.
  3. Requester is not a member of "XYZ" group.

Doing this based on a ticket group is not sufficient because we have many groups that respond and work in  multiple areas, so if I want to report on our "Vetting" team - they may be interacting with other groups on tickets, and I can't make a report where I look at the # of updates from users on the vetting team for the last week, organized by user. At least not without singling out each user, but this creates a huge strain creating and updating the reporting based on team changes/turnover/etc. 

Also, if we were able to do this we could cut down on the total number of reports by adding a dropdown filter to a dashboard to select which user group someone wants to report on. So the same "Ticket Updates" report from my example above could be used to serve multiple teams. 

Unless I'm missing something and you can show me how to do this, I haven't been able to figure out a way myself, or in the community or KBS articles. 


19

6

6 comments

I think I might be able to hack a solution using tags, but that seems like an unnecessary burden given that the group information already exists, and we would essentially have to maintain groups AND tag groups to make this work, when just maintaining groups should be enough. 

We should also be able to do this with custom Agent Roles. 

4


Upvote this

1


Seems like such an easy field to report off of.  Its hard to explain to our managers why a report shows a user belongs to multiple groups because its pulling the user group from the ticket not the user

1


This is such a weird thing to be missing and required me to build really stupid elaborate tagging schemas to basically track groups in a way that allowed me to report on them in explore. It also is confusing for non-technical people who don't understand why you can't do this thing that seems very reasonable. 

1


Also need to have a filter on the "Call agent group" (and "Leg agent group").

The use-case is the following: I need to output outbound call statistics for a team, and I can't even easily output the number of calls.
Indeed, what I need is to be able to select the group(s) of employees that I need to filter, and at the moment, I have to go through the "Call agent name" data and select the agents concerned one by one = when a new employee joins the team, I have to modify this filter and the others that I will be obliged to put in place. This is not maintainable.

In terms of groups, there are the following data but they do not meet the need: "Call group" because it is the default group of the instance, nor the "Ticket group" because a ticket is not created for each call. 

It is therefore the Group of the agent of the call (and Group of the agent of the leg) that we need.
Explore Talk's statistics should allow to output data also on the agents and not only on the calls.
It is also impossible to provide data about the time of connection of the agents to Zendesk and to the different Talk statuses (Example: on a given day, an agent has connected to Talk in online status Xh, Talk in absent status Xh, Talk in absent status and "On Call" sub-status Xh, Talk in absent status and "Away" sub-status Xh...

0


image avatar

Walter Bellante

Zendesk Product Manager

Hey Ryan, thank you for taking the time to provide us with this feedback. We apologize for the delay on our end in providing you with a response to your feature request.

 

We wanted to let you know that at this time we are not able to commit to building this feature. We understand this may be frustrating but wanted to ensure we closed this loop to remain transparent.


At this time we are going to close this post for comment and mark it as “not planned”. If you are interested in learning more about this and other features being built please make sure to check out and follow our Community events, What’s New Community Topic, and Zendesk Updates. Again, we apologize for our delay and appreciate you being a valuable Zendesk Community member.

-1


Post is closed for comments.

Didn't find what you're looking for?

New post