I though this would be standard from the beginning.
Surprised to read that it is not implemented.
Definitely a +1, particularly to have different access levels to different knowledge.

This is excellent news, and certainly a Christmas present I'll take. Being able to point to multiple spaces will really help with our KCS initiative and respond more quickly and easily to requests by having multiple sources of knowledge available and searchable, bringing a feature already available in Cloud into Data Center.

It's a SHAME how Atlassian milks existing on-premise customers and the majority of investments go to CLOUD products. DC customers are now paying a lot of money, and you are not able to provide this basic feature one year after it's available in CLOUD JSM.

Hi, this is a must have for our company! We did evaluation on JSM Cloud environment where we could link multiple knowledge base spaces, then we decided on JSM Data Center and now during deployment finalization we stumble upon this missing feature. It was delivered to Cloud over a year ago, please move it to DC version as well, it's a blocker for us given how we designed our business processes for our customers basing our evaluation on this being available.

Any updates on this?

It looks like this feature exists in Cloud- having it on Server would be very useful, especially since you can access Confluence in the Cloud version (but also only one Space). This would set our team up better for a transition into Cloud if it came to Server.

Any updates on when we can expect this in Data Center?

Any update on the Server solution?  Looks like Cloud is rolling out very soon.

Much needed.

@brianFrampton: exactly this setup was our goal. As stated in https://jira.atlassian.com/browse/JSDSERVER-170?focusedCommentId=1971557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1971557 we used our own fix as interim a solution (unfortunately the interim state lasts due to the lack of a upstream solution)

This would be very useful, espeically if I could link an internal KB for agents only, and an external KB for customers and agents to see.

Would be very useful for my company

someone saw the opportunity & provided a plugin for Jira Server

https://marketplace.atlassian.com/apps/1221742/multi-space-knowledge-base-searcher-jira?hosting=server&tab=overview

@alexander.schmid  : we achieved this with  https://gist.github.com/rlsit/15f9d1e99274cfdbd2b400ea6284965b

see: https://jira.atlassian.com/browse/JSDSERVER-170?focusedCommentId=1971557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-1971557

It would be also really great, if there could be different sections as "internal" and "public" knowledge bases.

This would extremely important for us. Not sure how this is still not implemented after six years.

This function would be excellent. We would also like a more granular approach and be able to select Jira Users and what Confluence Space they can be linked to. 

We have the same issue, I want to connect multiple spaces with one ServiceDesk project.

this is now almost on the top 10 list of most voted requests. Currently on #16. I wonder how much Atlassian cares about that? 

As they ask us to vote, I would hope it means something for them. If customer satisfaction is important it should not be impossible to solve top-voted issues in each update. 

We assumed this functionality was already built into JSD. We have the exact use case as many others here- one external facing Confluence Space while wanting to search multiple internal Spaces. We love that we can put our stuff into so many Confluence Spaces, but if they aren't searchable within JSD easily, it's like it doesn't exist.

Our customer is going to start using JSD. Not a good start when we have to realise that such a popular request is in an idle mode since years... :-/

We stumbled over this issue in 2016 and implemented a simple interim fix for us at the beginning of 2017.

I did not post our solution here, as it is really just a hackish and crutchy fix and very strongly tailored to our needs.

As the issue is still not resolved, I decided to publish our crutchy fix as a gist @ https://gist.github.com/rlsit/15f9d1e99274cfdbd2b400ea6284965b

It is a pure JavaScript implementation. If I knew we would use the interim q&d fix for more then 2 years I would have used a more robust implementation (script runner / web pannel / ...)

So I publish this code snippet in the hope someone might find it useful and with the express note:

• no warranty
• use at your own risk
• ugly code (I am no JS programmer!), combined with cerebral diarrhea:  you might risk to vomit

And I would be glad if atlassian releases me from my own ugly code with a 'professional' solution.

Our use case is precisely the same as Daniel's.

Completely agree. I can't imagine how this would be so difficult.

To be honest I think that, given the will to do it, this should be trivial to implement.

Another use case popping up for us. We serve internal and external users with the same ServiceDesk. Some articles of the KB are public, that others not. While one could go page by page selecting (via Restrictions) what is public and not, I find that extremely error prone. Our preferred approach would be to have two KBs, one public and one not, both connected to the same JSD.

Come on Atlassian. At least give some signs of life here...

Having had Confluence (And Jira software) for many years before service desk we have our knowledge spread around many spaces. Particularly for Agent Only use at a level 2 or 3 support scenario, it doesn't really make sense for us to have to realign or duplicate information in Confluence to fit in one single space to suit Service Desk.
We'd actually like it to be able to search all of Confluence, not specific spaces.

Having this capability and flexibility would be outstanding. Atlassian, please seriously consider this essential feature.

I think in total ( all requests regarding multiple spaces ) there are more than 600 Votes but nothing happens at all.

Thats very frustrating 

This feature would be very useful as our IT Team uses canned responses and internal documentations that external users shouldn't see. 

As we reference both External Help Desk articles and internal documentation 

Perhaps you could address the issue of user authentication from Jira to confluence knowledge bases first before opening up even more functionality?

https://jira.atlassian.com/browse/JSDSERVER-1551

I appreciate that this issue has been open longer (since 2013) but sure users need a seamless experience in logging into the service first before they even get directed to content?

Please make these issues a priority! I can't believe it has taken 5 years / 3 years to get to a stage of just "gathering interest".

This would be a super-useful feature. It makes little sense why to limit the search to one space only.  Also add the ability to link to the root (all spaces) in Confluence. Some companies are not that secretive, and need this flexibility.

We need this feature as we have two sets of customers, but with completely different issues to troubleshoot, and we prefer not to send them into the same experience.

Certainly need this. Not everybody runs a service desk per product and the likes of Freshdesk already allow client specific spaces only visible to certain companies.

Please move ahead with implementing this feature as this is now a non-starter on implementing Jira Service Desk until it's remedied.

We implement Jira SD now and we missed this feature very hard

We could work around it using the "hack" presented here: https://jira.atlassian.com/browse/CONFCLOUD-53598

Actually, I expected this to be possible. It seemed to be natural to be able to use separate spaces for KB and other documentation needs. Please implement this feature. 

Really really need this feature. Created 2013. Will it ever be added?

We are looking to implement the KB feature in our service desk and having this feature will help us have two partner facing KBs for our separate issues versus having to create a whole new one with both already set up KBs merged into it.

@Atlassian Please work on implementing this feature..

We could really use this feature! In our scenario, we're separating it by a space for an application specific KB and then a How to space for more general IT help.

Yes please we really need this feature, as it widens the KB search capability....  Very supportive of this feature!

ours too, please add this feature

We have another use case for this one - where we have an IT helpdesk with access to shared KB articles for general circulation to all staff members, and a need for other KB articles which are more technical, or contain confidential details / information / configuration settings which should only be available to IT support staff. 

When logging a support request / issues through the self service customer portal, the customer would be able to browse KB articles from the general availability confluence space and use them as necessary, but not those from the IT technical space. When the technician picks up an issue that couldn't be solved through the self service customer portal KB's they have the option to search the technical solutions as well as the generally available solutions from both KB spaces. 

Our Use case is the same - @Atlassian please implement this important feature

My use case is the same as already mentioned here. A company-wide first line support team that wants to access KBs populated and owned by other teams.

The other only option is to have a huge company-wide KB, but I don't thing that's feasible at all.

Of the course the first-line team will also have their own dedicated KB, that should be the one chosen by default when issues are "promoted" to KB articles. But then articles might get moved to other KDs

As 1st line support we want to be able to read article from other spaces to fully support our end users.

We have one JSD project for submitting to our team and the 20 products we support.   The challenge is that we have a separate confluence knowledge space for each product (20 separate Confluence knowledge space) 

Since Atlassian's implementation is based on the assumption that a JIRA Service Desk will have a 1 to 1 mapping to Knowledge Space, we are unable to use this feature.  

Our organizational approach is that each team has their own service desk project, however each team has multiple spaces.   This has made our Service Desk implementation less than idea.  we did try the other approach but teams reporting that they struggled to work through the 100's of pages.  

the current one to one relationship, just doesnt work effectively for an enterprise with a number of value streams/products.

this effectively stops us using it altogther...

We are looking for similar feature to be implemented by Atlassian. Hope Atlassian, rather waiting for votes, implement this feature as quickly as possible.

Definitively this is a must have. We have several Service Desks, each with its own Confluence Space, but we have another space which hold cross project documentation and right now we cannot link to the rest of Service Desk. Instead, we have to create en empty Service Desk just to link the documentation on this space, and have the users redirected there if they want to search for this type of content.

To fully transition my company from an in-house tool to Atlassian products, our workflow would require Service Desks for each product as well as for each solution which would be a collection of products. Each product would have a 1:1 relationship with a KB, but for the solutions we would like to be able to have a 1:N relationship. Until we can have a 1:N relationship between Service Desks and KB's, there would be too much manual work for us to use JSD.

This is required as I want end-users to see self-service knowledge articles, and I want my service desk staff to see backend solutions in the ticket while they are being worked. One KB for users, one KB for admins, both linked to the same JIRA Service Desk project.

I agree, we need to be able to link JIRA SD to multiple Confluence spaces, not just one. When will this feature be available?

This would be a useful addition for us as well, as we have need to use more than one confluence space, and both should link to SD.

For instance, I'd like to keep a known-errors database (KEDB according to ITIL) in a separate space from the regular knowledgebase, but it would be helpful for service desk staff to have access to the workarounds contained in those KEDB pages right from the issue itself.

That's just one instance where I would see its value.

I would support this improvement. We would like to be able to divide information into multiple spaces, with each space looking at different parts of our company. However we only want to run one SD.

Our organisation is a VAR for a software product. We provide unique and custom solutions to individual customers while supporting their use of a common core software product. We would like to create a common KB for use of the product, and then separate KBs to address particular aspects of each customer's specific solution. This scenario corresponds with the Description's second "use case."

+1

+1 - we'd like to have multiple documentation spaces searchable by unlicensed (but logged in) users via SD, without having to create a SD for each documentation space.

As a workaround, you can create a public SD and create a linked KB.

By default, customers will have access to the public SD too and on the

/customer/portals page will be able to search all KB's they have access to.

The downside is that you then have a (potentially) unwanted SD where tickets can be raised by customers (Although you could move them).

Hope this helps someone...

I'd like to see this. We have multiple service desks, each with a specific set of customers and a specific set of KB articles (related directly to them).

There are also a number of KB articles that have common relevance across all SD's. Copy/pasting across all SD's is frankly, a terrible idea, but seemingly is the only option.

Please implement this simple feature.

This seems like it might be simpler to solve than JSD-143. As the previous commenter mention, I feel like it might already be possible. Please offer some insight how this can be done.

problem: the SD setup only allows us to associate a single confluence space for search-ability.
request: we'd like to be able to associate multiple confluence spaces for search-ability within SD.

This is important to us, in order to use Service Desk:

Ideally, every single confluence page in specified Spaces should be searchable in the knowledge base. Alternative, each page could be enabled in knowledge-base search by flagging it as "add to knowledge base".

Thank you.

Was wondering the same thing.

This functionality is available on support.atlassian.com. How did you manage that at Atlassian?

Bump - really need this before we consolidate all of our platforms in production!

The reporter of this issue from Atlassian side seems to be inactive:

Hope this won't lead to forgetting this issue as it is indeed a very important one.

We would also benefit greatly from linking to more than one Confluence Space

We have a very similar use case as described by James Davis.

My use case for this issue is as follows:

I have multiple complex products that target a specific industry. My customers will typically only use one of the products, so I like to split my knowledge base up so each product is in its own space for browsing by the appropriate customer in Confluence. There is some shared KB knowledge across products, but most of the KB is very specific per product.

A support team supports all of the products for that industry - I only want them to have to look in one place for incoming service desk requests across all products for that industry. I'm planning to create just a single service desk for them to use for this group of products.

If there is only one service desk for my products in this industry, that service desk needs to be able to search KB articles in multiple spaces when creating a service desk request from the customer. I can create a request type per product and use the search tagging functionality to limit the KB articles searched when the customer creates a service desk request for that product - this keeps the KB search results relevant for the specific product.