Are there plans to provide archiving of community posts? (Community maintenance)

Hi Mary - 

Thanks for your question. There is not currently any sort of archiving function in Gather. What we recommend (and do in our own community here) is to create a topic that is visible only to Agents and Managers and then move posts you do not want visible to the general public into that topic to "archive" it. 

You can use the API to pull a list of community posts within a date range; I'll pull together some instructions on how to do that and post that here later. I'm also looking into whether the API can be used to move posts from one topic to another; I'll follow up in another comment about that once I can get more information. 

Hi @Mary Paez,

Thank you for raising this point. I think archiving of old posts is an interesting subject that I'd like to learn more about. To be truthful, I'm also looking at it from a Zendesk-internal perspetive - we sometimes ask ourselves how we should clean up our ever-growing amount of data in communities. Maybe a sensible auto-archiving and eventually deletion strategy can help both customers and Zendesk :-)

When you say "old posts", how would you define that? Is it simply based on creation time of the post? Or the latest reply or vote? Or some other characteristic? And approximately what timeframe would you have in mind if you wanted them to be automatically archived?

Hi Kasper,

Sometimes we have a 1-off situation where we pull individual posts and combine them.  That would be another nice feature: the ability to combine multiple posts b/c they are about the same subject.

To answer your question, since we are a software company, we have various releases during specific time periods:  Per1, Per2, Per 3.  I would like to pul the Per3 posts for a particular year as they are no longer applicable.  Those features were already built into the currect product.

Or, I might want to pull by Start date to End date.

It is helpful if we can pull these posts by Topic (Community). Eg: I will pull from the Announcements topic for a particular time period (start & end date) and not the Q&A topic.

It is also important to not only pull those posts but to archive.  In KM, the rule of thumb is to ARCHIVE, not delete.  This is in the event someone needs to view some of the older posts.

Many Product Managers have come to us to get a listing of all posts so they can go thru each recommendation to be sure each feature request is accounted for and we can address each.  Right now it is difficult to get them a nicely formatted list of these posts.  But, but keeping an archive, we can at least dump that data to a spreadsheet and try to format.

It would also be nice to allow the addition of dropdown list fields in those posts.  This allows us to build lists where the customer can preselect fields.  Those fields might specify a product feature / area or it may represent a type of enhancement.

I wish the posts were treated more like KB articles and the way we create/archive

I hope this helps.

@Nicole - Community Manager, any luck on pulling together some instructions on how to use the API to retrieve a series of community posts by date range? Also I am very interested in:

"I'm also looking into whether the API can be used to move posts from one topic to another"

Would love to stay apprised of something like this

@Kasper Sørensen, as a software company we often complete feature requests and have various UI changes that render a lot of posts irrelevant. Unfortunately there is a lot of content that I wasn't around to manage over the years so when users search the community they are greeted with posts that end up being revived despite their irrelevancy. For us, an 'old post' would be one in which the content is no longer applicable and is beyond an arbitrary date we may decide on. The idea of being able to archive multiple posts in a feature set with the intention of 'cleaning up' the ever growing amount of data on the community would be a welcome feature from our end.

HI Jason - 

Apologies for my delayed response! Here's the call you would want to use to get your list of posts:

GET /api/v2/community/posts.json

(You can see more about that here: https://developer.zendesk.com/rest_api/docs/help_center/posts)

To sort it by date you'll amend that call as follows: 

GET /api/v2/community/posts.json?sort_by=created_at 

And then you'll need to paginate the results, as you'll only get 100 at a time. So the call will ultimately look like this: 

GET /api/v2/community/posts.json?sort_by=created_at&page=2

You'll need to make the call for each page of results, updating the page number you're looking for. More information about pagination and sorting can be found here: https://developer.zendesk.com/rest_api/docs/support/introduction#pagination

Give that a try and let us know what questions come up. 

As far as moving posts between topics using the API, you could theoretically do it by pulling a list of all of the posts you want to move, deleting them, and then re-creating them. There's a way to do it if you have a bulk of posts you need to move all at once, but it honestly might be easier to just go through them manually via the edit post UI with a team of people and a pizza. 

Jason, good news - I stand corrected. One of our engineers pointed out something I had missed. 

Assuming that you are the Admin and you're moving posts within the same help center, you should be able to use the update post endpoint, so you CAN move posts between topics via the API: 

Here's the info on that API endpoint: https://developer.zendesk.com/rest_api/docs/help_center/posts#update-post

PUT /api/v2/community/posts/{id}.json

So the {id} is the id of the post you want to move, and then the topic id would be part of the JSON body of the PUT request.

@Nicole - Community Manager, no apologies necessary. This is tremendously helpful and I will follow up if I have any questions. 

I didn't consider the pizza and recruitment method so I will also consider that ☺️🍕.

(edited)

Per your second comment:

That's awesome! This will likely be the route I take. Appreciated.

I just wanted to leave a tip here for anyone else who may stumble across this in the future.

I would recommend using PATCH as the http method here instead of PUT for updating the topic_id. The reason why has to do with the differences between how PUT and PATCH change/update the existing record:

• PUT will replace/completely overwrite the existing document with your request payload.
• PATCH will only update the attribute(s) you specify in your request payload (in this case topic_id) and leave everything else untouched.

You can read more about HTTP Methods here