Best practice to maintain spaces for a support team

[Michiel S.]

Hi there,

I'm an administrator of the Atlassian stack in a large enterprise and am faced with a situation that I would like some feedback on from the community.

My team has its own team space (of course!) that is private, but we also have a public team space for employees in our company to share information about the stack, the various features it offers, the support we provide and so on. Public does not mean anonymous access is allowed.

Next to that we also have a knowledge base space which is connected to our Jira Service Management project and this contains mostly 'kb-articles' but there is overlap with the public team space and that is where it starts to become a pain.

We have even a couple more spaces which were used to collaborate with specific teams we have close relations with, such as ITSM and Change Management, but those seem not to difficult to merge into the public team space.

I'm mostly wondering if we should merge the public team space and the kb-space and possibly even merge the private team space with that as well and just set restrictions so we only have to maintain one space.

What are other people in large companies doing and how do you view this?

[Kristian Klima]

Hello @Michiel S. 

There are several types on Confluence that focus on creating sites from Confluence content.

We're using Scroll Viewport (supported by Scroll Documents and Variants) by K15t. We're actually building an intranet site from multiple Confluence spaces with different permission setups. Using Scroll Docs and Variants, you can go more granular and decide which sections and/or pages from any space, or sections of the pages, should be displayed in that site. 

You can have your own domain and control access by your SSO solution.

Other solutions are Refined for Confluence - which work slightly differently and are dependent on individual spaces' permissions.

There's also Instant Website but I have no experience with that.

[Michiel S.]

Thank you for the suggestions. It is not what I am looking for right now, but good to know.

[Aron Gombas _Midori_]

You write about "merging" but I think you could eventually consider the opposite direction: splitting current spaces to eliminate duplication.

I mean grouping the content like this:

• KB space that is relevant for everyone
• KB space that is specific to team A
• KB space that is specific to team B
• KB space that is specific to team C
• KB space that is specific to team A and B
• KB space that is specific to team A and C
• (other possible combinations)

Depending on how many scenarios are actually existing in the company, it can be an option (if there is only a few) or not (if it explodes to hundreds of spaces).

[Michiel S.]

Hmmm... this seems like the exact opposite of what I am looking for and I don't see the benefit of this. Most of the content is meant for all employees in the company and only some of it is just for our team because it is sensitive. Using restrictions can shield certain information that should not be exposed but having it in a different space is easier to configure (just once) as opposed to having to set this per page (tree).

We already have duplication that needs to be mitigated and use the include macro to show/share pages from other spaces because information needs to be in several places and that is extra work that I am trying to avoid by merging spaces. The standard include macro on Confluence Cloud has the limitation that it doesn't show the page is coming from another location and which location which is something that makes administration more challenging as well.