Why you should never disable Team Site creation in Office 365

It happens quite often when I deliver group training to my clients. I demonstrate how users can create SharePoint Communication and Team sites themselves without the IT involvement, and then I hear someone mutter in the background, “Oh, we do not have this button in our SharePoint.” :cry: So, with this post, I would like to share my opinion on this somewhat controversial subject of team site creation (or disabling of creation to be precise).

What is this all about?

By default, anyone in SharePoint and Office 365 ecosystem can create a new Communication or Team site on the fly. The users don’t even need to try hard to do this – sites can be created from a myriad of locations like SharePoint Start Page, Outlook, MS Teams, etc. At one point, I documented at least 20 different ways such sites can be created.

Just one of the many ways to create an Office 365 Group (Team Site)

What is the argument?

Whether a user decides to create a new team in Teams or a new site from SharePoint, behind the scenes, an Office 365 Group is created that ties a Site, Outlook calendar, Planner, and the Distribution list together. I have explained the Office 365 Group ecosystem here. So what that means is that if users intended to create just a site to store documents or just a space to chat among each other, users and SharePoint admins end up with a myriad of other bells and whistles they did not intend to have in the first place. This potentially presents an overhead and governance issue.

How to disable site and group creation

Not possible Out of the Box. There is a way to disable the above for most users, though, but this requires the use of PowerShell.

Why you should not disable Team Site creation in Office 365

OK, I am sure some of you will disagree with me, but I am not a politician trying to appeal to the voters here, so not going to say what you want to hear. Instead, I will tell what I really think and stand for. I am a huge advocate of giving users and employees the freedom to move around the cabin without impeding collaboration. Below I would like to outline the reasons for my “bold” argument.

The site is the “new” folder

Remember back 10-20 years ago when the only tool for collaboration was a network file share? You did not prevent users from creating and deleting folders, did you? Well, Office 365 group is the new folder if you think about this. It’s just now we got all these extra tools at our disposal in addition to a place to store files.

“Shadow” collaboration

If you do disable site and team creation, users will find a way around this. It’s just natural human psychology. If you prevent me from creating a team on the fly and I need to go through 10 levels of approvals and wait for days for the site to be created, I am sorry, but I am going to use my personal Dropbox.

What are the alternatives to disabling Team Site creation?

Training

Proper education has never hurt. When users hit a Create a Team Site button without realizing its consequences, I agree, this is not good. But with simple and informal Training and Education, such occurrences can be reduced or even eliminated.

Governance

Documenting proper Governance policies and establishing some rules of engagement is another good idea. At least nobody got hurt from doing so in the past.

Retention and compliance

If you worry about losing intellectual property, you can always set up retention policies and data retention periods, or, better yet, designate certain documents as records.

Monitor

Yes, it is never a good idea when users create new sites and groups they do not need, but at least they reside in your Office 365 tenant and not their personal Dropbox or Google Drive. At least you can see them, audit activity, and put necessary controls on top of them.

Group Expiration policy

This is a relatively new functionality that makes groups (and all its associated apps like Planner, Outlook, Teams) expire after a certain period of time. This is something that will help keep the number of sites under control. You would set this in Azure Active Directory, and you can read more about it here.