Brianne Reinhardt

Looking for an update here. Listing the users subscribed to sections, articles, topics, and posts should be a standard part of the explore dataset.

Same question as Dustin King, there is a report within the Guide: Community [default] dataset called “Posts by first comments” that is a pre-built attribute throwing an error. Is Zendesk planning to resolve this?

Hi Orsolya Forster! Any update here now that the community dataset is over a year old.

I agree with this request for Explore, I have to use the API weekly to determine if we had any new subscribers and supply their contact information to our Customer Success team.

I also think it would be beneficial to have a section in Guide or Gather for subscription management so we can see which users are subscribed to which topics, and unsubscribe them or add subscribers to a topic without having to utilize the API.

We are utilizing the new content tag feature and I've found a way to add a custom drop-down next to the other status filter and sorter on the post list pages. When a tag is selected from the dropdown it redirects the users to the search page for that tag. However, it would still be helpful to filter our posts by other statuses such as "unanswered" to allow users to see what questions are open that they may be able to supply an answer to (before our very limited number of moderators are able to review). I think "unanswered" and "in progress" are two valuable additional statuses.

Alternatively, I've requested a feature for filtering post lists based on content tags instead of redirecting the user to the search page. If this feature became available, we could just switch to using content tags for all statuses and I would hide the native status filter all together. My feature request is here if anyone else is interested in this use case.

Feature Request Summary: 

For the post and article endpoints to include a sideload for the content_tags.

Description/Use Cases: 

When calling the API to access the data associated with a post and article, the content_tag_ids are returned, but a second call is required to get the names of the content_tags via the content_tag endpoint.

Business impact of limitation or missing feature:

It utilizes a second call to the API to get the names of the content_tags, when it would be beneficial to utilize the same API call like we can do with posts to include the topics and/or authors (users) associated with them or with articles to include the sections, categories, and/or authors (users). Additionally, end users cannot access the content_tags endpoint, so this makes it impossible to cross-reference the content_tag_id names using a get without headers.

Feature Request Summary: 

The community_post_list_page and community_topic_page should support filtering the posts by one or more content tags.

Description/Use Cases: 

Users can filter the topic they are viewing (or all posts list) based on tags of interest. So if there is a Q&A topic on our product, they could filter on tags like adoption, configuration, tips, key-feature-name, etc. Similar to how they can filter on status currently, except it would allow multiple tag selections so they could further filter to posts that include all selected tags.

Business impact of limitation or missing feature:

We have limited community moderators, so we are unable to adequately move posts to appropriate topics. Especially since there is no backend interface to move posts in bulk. Additionally, more topics create more to read for our users, which means it takes them longer to find the information of interest. If users could simply filter a topic based on tags of interest, a single topic could support more posts, making it easier for users to choose which topic to post to and find information relevant to them.

Other necessary information or resources:

Currently, users must go to the search page to see any posts related to a single content tag and filter to topic from there - which is not a good user experience when they've already come from a topic. Additionally, they cannot see and filter for any other content tags at the same time to further narrow search results. And since the content tags API endpoint can't be accessed by end users, there is no way to give them a list of all available tags anywhere even with customization.

Is there a recipe for upvote count, downvote count, vote date, and user role, name, email for article votes? I see it for the Community posts, but not the articles.

Adding this here after discussing via a support ticket. Using the Community dataset:

1. Added Metric: COUNT (Community Events)
2. Added Row: Community engagement event type
3. Added Filter: Community post created at – Month and Selected a month I knew has some results of null or zero.

The event types that are null will not display even using Results Manipulation formula: COUNT(Community events)+0.

This is especially problematic if one of the types is null regardless of filter, because then we aren't aware that that event type is even tracked until there is data for it.

My request is to make sure all event types are included in the results even if they are zero/null, otherwise it's not clear what Community event types are captured and the results are potentially inconsistent week over week.

Thanks Nicole!