Curious- Are you allowing all users to create O365 groups or limiting self-service creation?

[John Peluso]

Hey all... just wondering how everyone else is approaching this. Group sprawl is a concern, but at the same time, business user agility is a primary benefit of Groups... SO...

Are you allowing self-service creation of groups accross your broad user population? If so, how are you planning to deal with Sprawl?

OR

Are you restricting group creation to a small subset of the population or to admins only? If so, how are you planning to handle group creation requests from regular users?

[#2]

We recently (within the last month) enabled self service creation.  When every group is created we append the prefix "Group - " to the group name.  We are looking forward to the Groups expiration feature that Microsoft mentioned at Ignite to deal with the problem of Groups that become unused. 

[#3]

I had planned for it to leave it open, but recently changed my mind because of "sprawl". The fault is our own and not really an issue at the moment, because my users aren't yet fully familiar with Office 365 and are mostly using Exchange Online at the moment. 

I ran a trial for a couple of weeks just to see what would happen, as as expected without training groups ended up for duplicate matters, users not remembering guidelines and not using expected prefixes.

In the last month or so, I've finally had the time to further refine the provisionin process and have manged to create an almost proper usage guildlines page in SharePoint where all requirements are explained and I have created a few default site classifications (all powershell by the way). Additionally I've created a request template in our ITSM solution for the purpose of request a group provisioning. This template includes additional information on usage and also asks for specific metadata about the wanted group. 

Once our rollout is complete (sometime this year), I expect to relax the provisioning process again, and allow it for a limited group (my so called Office 365 Champions).

I wish we were able to automatically create different prefixes for different kinds of groups (projects, organizational groups, and so on - one size does not fit us at the moment).

[#4]

Every enteriprise customer I've worked with wants them disabled or at least restricted to particular group of users. Then again, they did the same with regular DGs, so not much has changed.

[#5]

We have around 100 users and we will never allow anything in Office365 to be self service. The sprawl issue is the number one reason.

[#6]

Understandbly, but I kind of like idea of self-service in general. It's just not ripe in the Office 365 Groups case. I plan to connect my ITSM solution through PowerShell scripts to Office 365. 

In that way I can create custom request templates that ask for alle the neccessary metadata, and even get creation approvals, provision the group through powershell and still get self-service for the user (just not in O365 directly :P)

[#7]

IMHO, It really depends on each company, the culture they have there when trying new tools and services (a more classic company vs. a more dynamic company) and also the way people works (following guidelines vs. not following guidelines)

[#8]

thanks for the feedback everyone... keep it coming.

[#9]

We've disabled groups, but just recently created a security group of indivdiuals allowed to create groups, primarly because we have a large interest in Planner and want to allow some people to use that app.  I see a long-term vision of self-service but the controls to manage groups need to mature quite a bit so we can align internally with some policies and (such as a docuemnted bi-annual review of membership) and our risks accordingly.

[#10]

We have shut down Groups. I have enough problems getting people to use the Team Sites in SPO we have now, adding Groups would just complicate the issue and lead to some serious problems.

[#11]

Hello John,
We have been using groups for about 1 year now. It has been a great success with geographically dispersed businesses groups.
When we enabled Groups, we quickly realized the pain of identifying the groups by their oddly given names, and we decided to lock creation to a small admin team who would create modern groups and train biz teams.
However, much later on, we found people creating plans, were able to create Groups that way, and Group restriction usability is not as clear (to the user) as it is with Groups. Add to this the somewhat recent introduction of Teams, which has a clontrol of "everyone OR no one", and you end up with frustrated admins, power, regular, and even ocasional users.
So to summarize... Groups, Teams, Yammer groups, Plans, will enhance your business teams collaboration, including their clients. If you restricted the creation of Groups you quickly realize users will find another app that will creat the group for you. There are PS to ensure some naming conventions, but in a hybrid environment this could generate a huge effort to adjust the old groups to the new standard. I believe user awareness of standardized names are the key to maintain a well balanced self-service system. Users are good with file systems (in their majority), so if we give them the opportunity with Groups, I'm confident they will learn.

[#12]

Thanks Phil-- regarding the "create a Planner and get a Group even if Group creation is disabled"... i wonder if this is an artifact of Planner initially not recognizing the "no self-service creation" setting which was in the OWA mailbox policy but is now in AAD where Planner can see it. Hopefully that will stop that loophole for unsactioned users to create Groups.

[#13]

I echo some of the other comments here. If you want to encourage a collaborative culture, allow everyone to create Office 365 Groups. But it is best practise to create a naming policy to help "contain" sprawl. Using a policy to add a prefix helps identify them clearly as Groups in your Global Address List and Active Directory.

The next best approach is allowing a small group of people to create Office 365 Groups. 

If you do switch of Group creation altogether, your people may continue to look outside the boundaries of your control and use Shadow IT solutions to fit their needs. 

[#14]

Our company just migrated to Office 365 and by default we are disabling the group creation feature as soon as users realized they could create groups, I started seeing groups like test, etc.  Right now only the admins can create the Office 365 groups.

With teams on the horizon and using group creation to create groups inside of teams I'm not sure on whether to allow all to create groups.

[#15]

Indeed company culture and current way of working will influence how companies will make decisions. We are a large, international company with innovation deeply embedded in our culture. We have been promoting self service a lot and are not staffed to support central administration of Groups. Not offering Groups is not an option as our employees will start using other services out their on the Internet to facilitate team collaboration.

That is why we will enable self service creation of Groups with a naming policy (grp_ in front of the group).

[#16]

We currently require various security groups (Active Directory, PDL's, etc) to be verified semi-annually to comply with SOX requirements.  Do you have similar requirements?  If so, have you integrated the review of O365 Group memberships into internal processes?  How have you done that?

[#17]

Is there any specific documentation you can share on the provisioning process and best practices for rolling out groups.  

---

@Ivan Unger wrote:

I had planned for it to leave it open, but recently changed my mind because of "sprawl". The fault is our own and not really an issue at the moment, because my users aren't yet fully familiar with Office 365 and are mostly using Exchange Online at the moment. 

I ran a trial for a couple of weeks just to see what would happen, as as expected without training groups ended up for duplicate matters, users not remembering guidelines and not using expected prefixes.

In the last month or so, I've finally had the time to further refine the provisionin process and have manged to create an almost proper usage guildlines page in SharePoint where all requirements are explained and I have created a few default site classifications (all powershell by the way). Additionally I've created a request template in our ITSM solution for the purpose of request a group provisioning. This template includes additional information on usage and also asks for specific metadata about the wanted group. 

Once our rollout is complete (sometime this year), I expect to relax the provisioning process again, and allow it for a limited group (my so called Office 365 Champions).

I wish we were able to automatically create different prefixes for different kinds of groups (projects, organizational groups, and so on - one size does not fit us at the moment).

---

[#18]

Nothing special, as the provisioning process is just on the organizational side of things. I have groups for departments, department-overarching groups and project groups at the moment.
Exchang Mailboxes are already in EXO. Document are being transferred currently (within the year) to SPO to all the respective groups.
AS for the group creation. I just let my users fill out a specific request form and trigger multiple tasks for us (IT). Things like namechecks, create group, edit settings (time zones, languages, ...). That's it, after that I transfer group ownership to the requester.

Aside from all of that, I have a small group that gets regular Office 365 Updates from me directly - also through an Office 365 Group.