Why do you disable space creation?

[Ned Lindau]

Hi amazing admins,

My name's Ned, and I'm a PM on Confluence. I'd love to learn the reasons why and how you decide whether to enable or disable space creation permissions for a given user or group.

Would love any and all responses, including the rough % of users that you think are able to create spaces today, any frameworks you use (could be formal or just in your heads) to make the decision, or any other relevant info you can think of. Thank you!

[Tomislav Tobijas · Accepted solution]

I agree with @Nic Brough -Adaptavist- here. In most environments I've usually seen chaos when it comes to spaces in Confluence. You can definitely draw a parallel with who can create Jira projects. Basically, whenever we come to some existing client environment, the default option for everyone having the ability to create team-managed projects was enabled and you had billion of projects where somewhere there was only a couple of issues. The same goes with Confluence - if you give creation rights to a lot of people, you'll probably end up with 2-3 spaces containing same (or almost the same) content and people won't know where to look for information. Regarding the % of users who should be able to create spaces, I would probably say somewhere around 10% of total active users, but that might differ depending on the org size (in smaller orgs that % would probably be higher, while in large orgs that would be maybe even lower). You can always have personal spaces to write some non-specific content, but the proper hierarchy and structure of the content should be clear to everyone so the searched information can be easy to find.

[Ned Lindau]

Thank you! Maybe a silly question, but what's the problem with users creating a lot of spaces? Is it just that creating lots of spaces makes finding content a lot harder? Or is there another problem?

[Tomislav Tobijas]

@Ned Lindau it all usually leads to that - having content scattered around. I often hear clients saying that they want to move to another platform (from e.g., SharePoint) due to a fact that they have files and folders 'all around the place' and then they start doing the same thing with Confluence. You can, usually, design a simple structure within the documentation so that everyone knows where something can be found. Again, as Nic said, mostly, only a few people within the organization know how to structure and maintain that content on the global level > these people should be able to create new spaces. When it comes to existing spaces, I know that you can utterly create chaos there as well, but then it would be up to space administrator to maintain the space 'health'.

When you open a site where everyone can open spaces and create content, it usually ends up with someone having a big headache after asking who's the content owner and which information is up to date 😅

[Nic Brough -Adaptavist- · Accepted solution]

For me, it was always more about "who should be allowed to do it".  Most of the Confluences I've looked after or helped out with are large, sprawling, and have a problem with useless content.  

There's a range, of course, but most Confluences are trying to get to, or conform to, some form of structure (albeit not a fixed structure, it's expected to evolve), and letting everyone create a space is not useful.  It needs to be limited to people who understand when it is the right thing to do.  That could, of course, be everyone, but often, especially in larger places that want structure, it's rare that everyone has that understanding.

[Ned Lindau]

Thank you! In your mind, when is creating a space the right thing to do? For what purposes does a new space make sense?

[Nic Brough -Adaptavist-]

It depends on what the people using the Confluence want from it.

One real-world example, one of my customers runs a website that is in the top 50 most visited in the world.  

The site is fragmented - last time I was there, there were seven core areas of the site, all owned by very different parts of the organisation, but having the same branding and similar CMS systems behind it, and then almost 700 dedicated applications running sub-services that the CMS really couldn't handle.  (Think of something like a newspaper - the CMS can handle articles, embedded video, and comments, but you need another service to provide the online crosswords, puzzles, adverts and so on)

The operations team responsible for supporting the production site use Confluence to document it, and their structure is simple - one space per sub-service they have to support.  Those spaces have a rigid core structure so that the ops team can always find what they need when they are deploying, maintaining, upgrading, or debugging a specific service.  (But it's fine to add stuff outside the core if it's useful).  They can't memorise the 700 (especially as the turnover can be as high as 20 a week being added, deprecated, or upgraded), they rely on Confluence spaces with clear standard names, structures, and keys etc.  So they do not want people creating Confluence spaces that do not conform to standard. 

The right times for this customer to create a space is

• when they start a new project (meaning sub-service) - the space will be flagged as "not live" until deployed, and it won't be deployed unless the standard structure the Ops team needs is all filled and validated
• when they create a new team
• when the start a new project or initiative which is not a sub-service

It's not "no new spaces", it's "we need people who know what they're doing to create them to standard"

[Tere Pile]

Agree w/answers below, I've adopted a 'program/project' 'group allowance, we have 500 users of that about 20 are allowed to create spaces.  This generally aligns w/the ability to create 'team projects'.  Company projects is limited to far fewer persons.  

[Andy Gladstone]

We have ~150 active users in our Confluence site. I have always had the approach of less restriction = more creation and as such we allow all users to create spaces. I'd rather monitor and correct content than have users feel restrained by permissions, or lack thereof, and not contribute or collaborate in the space. I am lucky that we have pretty good Confluence hygiene and don't have a sprawl that could come about with more restrictions. Yes, every once in a while we will need to move content from a space and then archive it, but that benefits we reap in a less restrictive environment outweigh the risks.