Team Creation Governance

Frequent Contributor
Hi all,
I have gone through so many online resources and understand that it is recommedable to control the creation of teams to selected users.

It would be great to hear from our community users about the best practices, pain points, lesson leaned based on real example about how you are controlling the creation of team governance in your organisation?

Many thanks.
6 Replies
best response confirmed by Badal Ratra (Frequent Contributor)

In my experience, smaller organization/companies rarely is restricted creating groups! It adds value to be able to create teams/groups to communicate and collaborate in the way the users like best

Larger organization/companies with many users tend to restrict group creation more often due to that it can be very frustrating administrational wise. A lot of groups everywhere with no or little purpose can be a hazzle..

Also it depends on what kind of data the organization handles..Is it very sensitive data, it's a good idea that this data is controlled in a better way than unsensitive data.. You don't want this data spread all over!

You can utilize other methods as well as group expiration - to get rid of unused groups for example



Thanks Adam. Cheers!
I think allowing group creation to everyone is bad things waiting to happen and a mess for IT to keep / clean up. But it's a great debate that everyone has their own opinions on. It can go either way, IMO it really depends on how bright your user base is.

I can give you some best practices based on what I've seen round the world. There are different types of teams and therefore different kinds of governance. This is widely influenced by region, industry and size of organization.  It is however based on the principle of allowing ALL users to create certain types of teams but managing their lifecycles and controlling the creation of very large or org-wide teams.  We must learn from the lessons of the past where overcontrolling solution creation leads to shadow IT.    Very roughly it should go like this: 


1. The "official" organization/division/region Team - think "Northwest Sales" or "WorldWide Marketing".  These teams, which are usually mirroring a part of an organization, are best created by a Champion / IT member before anyone comes into the team.  Think of it like reserving a domain.  You want a particular name and to configure it a bit so makes a useful first impression when you add everyone to it.  Normally a core group spends an hour or tow defining an initial set of channels that should be there and defining their working experience themselves.  You really want the team who will live in the house to decorate it themselves i.e. do their own setup.   This team may exist as long as the organization or division does.   If your tenant is less than 1,000 users the org-wide team would fall in this category because you want the "right" name and design for any team where everyone will be a participant.


2. The Cross Organization project - Think "Product Foo Launch" or "O365 Service Management"  - The main leads of this project create the team and together also design the channels as above.  It is normally created by someone out in the organization, not IT but best done with a champion.  Certain templates can be very useful here.  This team has a long shelf life but not forever meaning when Product Foo is launched a new team for Product Foo Customer Service or Improvements might replace it.  Which is why I advocate for "Product Foo" team instead of limiting a team name based on a moment in time :)  Then you are just retiring the "Launch Plans" channel not the team itself. 


3. My Project Team - These are teams spun up and down very rapidly and in a perfect world by anyone.  We do advocate to all users that they look for a team before creating a new one but people will be people.  This is why lifecycle management is key.  By implementing this at the O365 Group level you can expire groups and keep better hygiene while not introducing unnecessary friction.  


What hasn't worked well. and didn't in the SharePoint days either. is too much overhead on group creation.  People will bypass it and end up sharing things in unapproved. insecure apps or just over email which has its own issues.    The best approach we believe is a mid line one - authoritative and larger scale teams are created in partnership with a Champion or IT while smaller on demand teams are allowed to be created by regular users in an environment where lifecycle management is in place.


It is worth it to note that you can control which type of a user can create Groups.  For instance, inside Microsoft you must be a full time employee to create a Group/Team.  Supplier accounts are not allowed which helps us also manage the expansion.  


Hope this is helpful

Thanks Karuana for sharing your experience and helpful information.
IMHO this should go right into the teams documentation as Governance Guidelines... Good write... Thanks Karuana