Confluence Structure For IT Department

[Roey Miterany]

Hello,

We are building our internal information space in Confluence. As we want to create it with the correct structure, I need to understand the best practices for our use case. 

The Confluence space will include technical and non-technical pages/articles to serve the entire team. We are thinking about the following structure. 

• Applications or Platforms
  • Application_1 / Platforms_1
    • How-to
    • Application Documentation
  • Application_2 / Platforms_2
    • How-to
    • Application Documentation (if applicable)
• Projects
  • Platform (can be with the same name as the Application_1 / Platforms_1)
    • Project_1
    • Project_2
    • Project_3
  • Platform (can be with the same name as the Application_2 / Platforms_2)
    • Project_1
    • Project_2
• Policies & Guidelines
  • Roles and responsibilities
    • Team_1
    • Team_2
    • Team_3
  • New Employee kit
    • Team_1
    • Team_2
• Team
  • Events
    • Topic_1
    • Topic_2
  • Group meeting
    • Topic_1
    • Topic_2

[Nic Brough -Adaptavist-]

hi Roey,

That makes good sense, but I would put some thought into how exactly you would do it in Confluence.  Confluence is a wiki and hence has unique page names. 

Using an example from an old client, they looked after ~600 different services and applications, and the production support team needed a very standard set of pages within them.

They could not do:

• Space: Production Maintenance
  • Page: Application 1
    • Page: Description
    • Page: Runbook
  • Page: Application 2
    • Page: Description
    • Page: Runbook

Because "Description" and "Runbook" have been created for Application 1, Application 2 can't create the pages they need.

So what I would do is describe your four headings in bold a "types of space". 

Application 1 and Application 2 would be application or platforms spaces, each team gets its own space and so on.

Couple of other tips

• Do not try to use prefixes in space names, it can cut the end off the space names, and makes search clunky.  Let the page tree do all the work
• Avoid special characters in space names, use words and numbers only.  This lets Confluence give you urls that are in plain text, rather than having to remember the numeric page-id that it falls back on if you use something like #?/ etc in the name

The place I used as an example, any one of the production team could pick up support from just the name off the application.  For example "Mr Flibble has gone mad!" - the support person knew instantly they need to go to confluence/browse/mrflibble/runbook despite never having heard of it!

[Roey Miterany]

Hi @Nic Brough -Adaptavist- ,

thank you for the detailed answer.  

can you share if we create multiple spaces, can we have it in one space (like references)? 

[Nic Brough -Adaptavist-]

Sorry, have what in one space?

[Roey Miterany]

You mentioned to create different spaces for our use case, the thing is that we want all data/info be in one space. Is it possible to link the main page (which include the sub-pages) from each separate space to one? Like reference. 

[Nic Brough -Adaptavist-]

If you put everything in one space, you will not be able to have pages with the same name. 

If Application_1 and Application_2 want to have a page called "Description", then they will not be able to, and you'll have to kludge some silly and pointless naming convention together and then try to impose it on your users and then handle all the problems it causes with searches.

Why do you think you want only one space? 

One of the great things about Confluence is that it has spaces, enabling you to set up separate areas for different purposes.

Your teams, projects, policies, and applications areas probably want to work differently, and one space would force them all to work the same way, with one set of templates, one set of formatting, one set of standards, and an imposed naming scheme which someone would have to explain and try to enforce.

But yes, another powerful part of Confluence is how you can get pages to work together.  All of its functions work across spaces, the space is just a container and an organisational structure. 

At the most basic level, you can link to other pages (in any space) with an internal link, which has the advantage over a URL that if you rename a target page, or move it somewhere, the link continues to work.

Then there are the "include" and "excerpt" macros.  These let you render a page, or part of a page, as though it is part of another page.  So if you have text you want to repeat in places, then you can create it once, see it in many places, and when it needs updating, only have to edit it once.

[Roey Miterany]

Thank you for the detailed explanation. 
I’ll give it a try and see if it works for us. 

[Tom_Carrott_Adaptavist]

Hi @Roey Miterany 

Interesting post! 

I'm a Product Manager @ Kolekti (Part of The Adaptavist Group). 

We are currently in discovery for a new Confluence Cloud product and are particularly interested in the content planning/creation/management problem space with Confluence Cloud. 

I wondered if you'd be interested in having an informal chat?

Many thanks,

Tom