Allow articles to be posted to multiple sections

@Peter, very well said. There do seem to be a few logical ways to make this work and we haven't gotten a solid answer from Zendesk as to why they haven't explored any of these options.

Zendesk, please listen to your users! There are things we love about Zendesk but the cons are beginning to outweigh the pros and we will need to leave the platform out of necessity if this doesn't get addressed. 

Hi all,

I'll gladly provide you with some updates as to our current thinking and direction.

Let me start by acknowledging the use case. We do want to support this. So it's not currently a question of whether we want this feature or not. It is down to how to do it and when to do it.

I have also acknowledged this in my extensive answers from May and July this year, although I understand it can be difficult to get a full picture of my thinking because I spread it out into several different comments. Oh the joy of having an ongoing conversation and the challenge of keeping up with it afterwards ;)

How

There are certainly different ways to do this. What we want to do is the right thing that works for all our customers. We also need to make sure that we build something that is sustainable and doesn't cause problems to other things we want to introduce into our product in the future. This was what happened when the original category/section/article tree was built. It was built in a manner that made it close to impossible for us to expand to have the article live in more than one section without significantly rebuilding it.

A few suggestions have been mentioned here and we have definitely been through these as well. A lot of what I do is to ensure that we have explored many different options. 

I think Peter has summarized these pretty well, so let me comment on the individual suggestions:

Allow dynamic linking of article CONTENT so that one article is the source of truth. 

We have investigated the same thing. Currently that is not possible due to how access restrictions are built. Since access restrictions are defined on the section level, an article could have many different access restrictions if we allowed it to be published to multiple sections. This in itself would be difficult for us to calculate, because what if a user has access to one section but not the other? What should we be honouring, how can we calculate it technically and how do we make sure it's understandable both from a Manager perspective and an End-user perspective.

If we were to link between the articles, we would have to know if the user would actually have access to the article and with our current implementation that would be a very demanding query which wouldn't scale. It would be even worse if articles could have multiple access restrictions.

Some of you might be okay with links being visible that then wouldn't be accessible after clicking, but I have had numerous conversations with other customers who want to ensure that customers don't see something they can't access.

Each article are unique articles, thus breadcrumbs will be through the correct category -> section

What we've seen in conversation with other customers has been that sometimes you want the articles to be separate, sometimes you don't. For example when it comes to metrics. You might want to measure the performance of the article no matter what section it's in. You might want votes to be the same, so users voting for the article in one section also vote for it in the other section. Other times you want to split those up completely and measure each article's performance for each section it's placed in.

It's the same when we look at article comments. You might want those comments to be the same as they address the same content rather than be split.

I can definitely understand that you might not have that specific requirement in your organisation, but we do see this from other customers. 

What we might do specifically for this use case is introducing a way to duplicate articles, so they could indeed be separate entities. But that obviously means that maintenance of these will be more difficult, as you would have two copies of the same content that you would have to maintain. We have already built a prototype for duplicating articles, but the way attachments was built means that we need to make some significant changes there before we can introduce the feature.

When someone searches for some content in the article, it links to the source of truth, but display a note beside the article that this article is also in X other sections. 

Yes, we are definitely going in that direction too. No matter what we need to have a canonical article that we link to by default. But showing that it appears in other sections would require either new components in our Curlybars theming language or changes to the breadcrumbs. But both those things are definitely in scope of what we are looking at right now, we just need to ensure we build a great experience.

What are we planning to do?

We are knee-deep in going through all of this with a dedicated team. Being able to publish the same articles into multiple sections is tied to two other projects: Being able to have more than 2 levels (category, section) and being able to publish the same article to multiple brands. These things are all tied together, so we need to holistically understand how they interact, before we can nail down exactly which feature to deliver first. We might deliver one before the other, simply because that is how we can technically build it in a sound manner.

When

As mentioned we now have a dedicated engineering team that is focusing on publishing content, including to multiple sections. This team is a newly created one and ensures that we get some much needed focus on this part of our product.

Unfortunately I can't be specific about timelines yet, because we are still going through everything and making a plan for how we get this out. We need to understand if we need to migrate from the old to the new functionality, if this has any implications on our API, what consequences this has on our Curlybars theming language and what it means to our standard theme Copenhagen.

Once we understand these things we will start to build them. Some of that work will be visible in that new features will be launched. Some of it won't be visible, because we need to do significant changes to our infrastructure to support this. As we progress we might make other decisions. We might see something that we need to attend to urgently or that there are certain tasks that we need to do before we can do publishing to multiple sections.

As you know prediction is very difficult, especially about the future. What I can see now in the crystal ball is that you should not expect these features for at least 9 months (and it could definitely be a lot longer). There is simply too much work for us to complete in that timeframe even with a dedicated team and we still have many unknowns at this stage that could influence our timing.

As we progress through this we'll know more and more and I'll gladly continue to provide updates, because I understand that this is causing significant pain. That is why we have started up a new team to focus on this.

Thanks for the update @Christian.

+1 from me for publishing articles to multiple sections.

Developing a SaaS application myself I understand all of your reasoning, and it most definitely is far more complicated to build something that gives all customers what they want.

The technical limitations surrounding components like access restrictions is a big one for many I agree. Not for me, but I also want those customers to get what they need also!

Thanks for setting up a specific team to investigate this capability. Look forward to enjoying whatever you manage to build for all.

Dan

+1, this would solve an issue we're having trying to organize our content! Hope it comes around soon!

Thanks for the update on this issue. I've just been reading the trail of this thread - what a journey!

It's good to hear that this is now actively being worked on, hurrah. Just another use case for you:

I run customer support for a charity, and we help other charities recruit volunteers through our online platform. We also work with area based recruiters too, who often help charities with their recruiting. As such, our KB is pretty neatly split between potential volunteers, charities, and those area based recruiters. It's really great for us to nod people towards support by saying 'go here, and look under the heading 'support for volunteers'', for example. Having everything there for them is great, but some info users need is the same between sections.

We're definitely not in the same boat as others here, needing someone dedicated to update these sections (we are a very small charity - and therefore very grateful for the legacy Zendesk level we are on!), but it would be great to reduce the clutter, so to speak.

Thanks for the update!

+1 to this. I think any site that supports products that are built on similar technologies/principles would need have this as an essential component to avoid messy maintenance.

We have articles that fit in 2 different topics and wait our users to be able to find it where they are looking for it.

Luise,

Thank you for participating in this discussion. It would be great to hear more about how exactly an article fits into two different topics. If you could elaborate a bit on that, that would be great.

Everyone,

Thank you for providing specific use cases. It definitely helps us to understand if we are moving in the right direction. There's a lot of infrastructure work that we need to do before we'll have this feature, but we are indeed still working on it with a dedicated team.

Another vote for this feature. We would like to include certain articles in a "getting started" section in our help center without the need to have two separate articles. It's too easy to update one and forget about the other.

For example, in the context of a dating website we provide information about searching and communication in their respective sections. There are certain articles that we would like to highlight in a separate section called "Getting Started" that goes over the basics.

+1 on this request.

We are a VAR handling equipment and software from various vendors. We want to maintain a central repository of end user oriented guides and give each customer a custom subset of these guides based on the deployment at their site.

We have HC set up so each client gets generic info (common to all clients) and a section with info and docs that is particular to their environment. Each customer has a section in HC that is restricted to people from that Organization.

Being able to "share" info from our central repository into a client section would be a huge help. Cutting and pasting existing articles is a logistical nightmare.

Christian,

The whole premise of the WWW is in being able to have multiple links pointing to the same page from all sorts of different places.  You want specific use cases? The whole Internet is a use case!

Here's a specific example:

We have weekly Webinars that we run. We want users who are interested in our webinars to be able to view the webinar section to see the latest releases.

However, each of our webinars cover different topics. One week, we talk about SEO. The next week, we talk about Call Tracking.  We want our webinars to be able to "live" in one spot (the webinar folder, for example), but we want to be able to create multiple links across our site from each of the specific topics that were discussed in that webinar.  One link from the "Call Tracking" section. One link from the "SEO" section, etc.

The internet is built to do this. You really need to find a solution for this issue! You have SEVEN pages of posts of people requesting this feature! SEVEN!!!

The amount of posts requesting this feature is ri-di-cu-lous!!!!
Zendesk needs to start loosing business. Their KB solution is not KCS friendly and far away from it (only has a few features that the company I worked forced them to implement in a record time).

SalesForce ServiceCloud and BMC are by far the best alternative than ZenDesk. They have the best KCS features and reporting out of the box, no customization required. Guys do your homework!!!!!!!!!!!!!!!

The PM does not give a crap about this feature otherwise it would have been prioritized long time ago. They keep asking for use cases just to burn everybody's patience and wallets.

Every single KB platform has this feature, every single KB platform except for Zendesk.

There are a few folks that work for Zendesk that are awesome people but product leadership is inexistent. Very, very, very sad.

We need this too!

Luise,

Thank you so much for adding your use case. It helps us to understand if we are indeed working towards the right goal. Currently categories/sections bundle together three distinct concepts: Context, Distribution and Access. Because access restrictions is set on a section level we see some customers who "simply" want to put in different sections because they have different audiences that need access to the same article. We're working on other things to make sure that you can deliver the same article to different audiences, even if they are in other sections.

In your case though it's a clear cut case of wanting the same content in different sections that the same user has access to. It's about the fact that you have different contexts (All webinars togther or a single webinar together with other articles on the same topic) and we're definitely working towards that goal, so thank you for giving us your use case. 

Jill,

It would be great to also hear a specific example from your organization. Since posting in different sections can solve many different problems it helps us to understand how you would use it in your case.

I consider this very basic functionality for a help center. It would serve everyone well and probably add to more sales too.

+1

+1 For us, this would be really useful!

+1 for me too.

My use would be as follow. We have several sections which are restricted to certain labels. Some articles are the same for more than one section, other articles are special for the section. That is why I would be glad to be able to show articles in more sections.

@Hans Latour

Yours is exactly my use

Hi Hans and Merav,

Could you elaborate a bit on who you are targeting with your restrictions? Who are seeing one section and who is seeing the others? It helps me to understand why you have built up your restrictions the way you have as that all ties into the ability to publish to multiple sections.

Hi Christian, here we go with an example: 

Enduser 1 uses product A (and has label "product_A")

Enduser 2 uses product B (and has label "product_B")

The section about product A is restricted to endusers with label "product_A" and has 2 articles which have the same information as for product B and 1 articles which is specific for product A.

The section about product B is restricted to endusers with label "product_B" etc...

As follows:

Section A has 3 articles A1, A2 and A3 

Section B has 3 articles B1 (copy of A1), B2 (copy of A2) and B3 

We now have to copy/paste articles and have to maintain them synchrone which is "dangerous" as you can understand.

So if we could use article A1 and A2 more times in other sections .... [happy_face] 

Another solution (for my problem) would be to extend the use of labels to restrict users for articles (now its only possible to restrict sections).

In the above example the content would be as follow:

Section A and B are restricted for users with labels "product_A" or "product_B".

Articles are:

A1 and A2 (take the rights from the section)

A3 restricted for label "product_A" only

B3 restricted for label "product_B" only

Like this every users "sees" the right articles.

My guess is that this is a bit more complex and not so broadly wished by other users, but I couldn't resist .... :-)

Thank you for that! A few follow-up questions:

1. Why do you restrict content so that users can only view content for the product they purchased? Is that because they really shouldn't see it or is it because it just creates a better experience that your end-users don't see content for products they have not purchased?
2. What is the content of the article you want to share? Why is it the exact same content for these different users who have purchased different products?

Hi Christian,

We've been Zendesk customers for a long time now. This is the ONLY post I follow. As a Product Manager, I understand you need to know the use case and rationale to design and implement the correct feature. But in this particular thread, surely by now, after all the years, you have enough use cases and customer "asks" to know your customers want and "need" the ability to repost the same articles in different sections. And if the content could be linked so that a change in one article, also is rendered in the duplicate article.

Sure, there are workarounds. We use them. But this does not necessarily resolve the issue.

I also understand it may introduce errors, such as unwanted, or multiple search results, breadcrumb issues, and handling access restrictions, as well as category/section limitations.

And specifically, you said you want it to be a features that is sustainable and meeting all customer needs.

• You won't be able to meet all customer needs. But you can see, there are  "many" unmet customer needs with this feature now. 
• Being sustainable? Sure, but as the system is now, it is not sustainable as this is why it is so difficult for Zendesk to add this feature today. 

As I see it, Zendesk puts out updates all the time. In fact, I see notices for an update for Help Center for April 4, 2017...so changes are possible. In fact, if Zendesk doesn't change with the times, your customers will.

I would suggest you develop some form of incremental feature, rather than wait until you hear every possible use case, design for every customer need, and then shelf the project because the T-shirt development cycle size is too large! :o)

I like Zendesk...even with all the quirks, but this customer "ask" is more than a quirk, and your customers are saying it all over this thread.

I haven't read all 206 comments but I'm sure mine will be redundant - we have numerous articles that need to be in both the Getting Started category and the Knowledge base category. Unfortunately, duplicate articles is the way we have to do this. Also unfortunately, Automatic Answers/Answer Bot (which is testing well, btw) suggests the same content twice. Not good.

We have multiple brands that often have the same article, but may have a product name in it. Would be nice to be able to create the article once and select the different brands it should be posted to. There should be conditional text that we can use within an article that when the article is published to a certain brand, that the brand name appears. So if <brand 1> is in the article when written, when published that text is replaced with the actual brand name. 

+ 1 for this feature request

James,

We are definitely not waiting for every possible use case before we start building. But the more information we get the better and why not get some more details while we're building this to ensure that we are still on the right track? While there is a lot of feedback in this thread, most of it is not focused on concrete use cases, so it's great to hear what the exact use cases are. It all helps us to understand it better.

And I can definitely guarantee you that we are building as incrementally as we can. But this is changing the entire structure of Help Center, so just doing minor changes will have significant impact on the entire product. It just takes time to build. There is no doubt that if I could deliver this faster I would. Although I do enjoy writing to all of you ;)

Greg,

Why do you want the same content in getting started and inside the knowledge base category? Could you give me an example of an article that you want in both getting started and in knowledge base? Have you ever considered doing a list of links to other articles as your getting started guide, so you didn't have to duplicate? Maybe you already looked into this, so I'm curious why that would not be a viable option for you.

Barry,

Publishing to other brands is probably a slightly different although related feature request. I would recommend you to add your vote and feedback to Share articles across multiple brand accounts so we keep it in the same place.

Christian, we want to walk new customers down a path in Getting Started, but not overwhelm them with every article on every subject like you would find in the Knowledge Base. There might be a Navigation Bar article in a Getting to Know the Software section of the Getting Started category. That Navigation Bar article might also exist in a more exhaustive User Interface section of the Knowledge Base category.

We're using a list of links as a workaround but it's not a good one because once the user opens an article they're off the Getting Started path (the left side article nav is no longer related to Getting Started). Let me know if you need further explanation.

Please focus on FUNCTIONALITY rather than cosmetics.  +1 on this thread!