Naming New Office 365 Groups Intelligently Is !Important

Sympraxis is starting a new Office 365 -based Intranet project with Sue Hanley (@susanhanley). Julie (@jfj1997) and I are really going to enjoy working with Sue!

As always when we’re starting a project, we want to start collaborating with the client project team in the tools we’re rolling out for their organization.

It’s a funny thing, but I often get push back on this, especially if the project team is IT-based. If the project team won’t use the tool set, then it’s not reasonable to expect everyone else to embrace it. As I always talk about in my Creating a Great User Experience session at conferences, excuses like “it’s too slow” or “I don’t like the UI” are serious problems that need to be addressed right up front. (And no, I’m not making this up.)

Anyway, Sue and I discussed this, and imagine the conversation going something like this…

Me: I think we should spin up a site where we can work with the project folks. Suggestions on the name and location? I would go with a subsite from https://[tenant]sharepoint.com, maybe “New Intranet”, with custom permissions.

Sue: Do you mean a team site for the intranet project? Why not a Group so we get a separate site collection?

Me: Doh! Of course! I’ll set it up. [Note: I’m still getting the hang of this whole “Groups” thing, clearly!]

Sue: Thanks! I am using one for [my other client] and it is actually great.

Me: Public or Private? And can you change that after the fact? (I sure hope so.) I’m thinking “Intranet Project 2017”, in case they want to do another Intranet Project later. Naming these Groups for good governance is a pretty tricky thing, IMO.

Sue: Private. That sounds good for a long name, but short name for the URL, right?

Me: Looks like I can shorten the Group ID. “IP2017”?

Sue: Works for me!

Me: This little exchange shows me that picking a good Group name and ID is REALLY important. Blog post!

Obviously, my first thought was not a new Office 365 Group, and I should really start thinking of it as at least one of the first options in cases like this. I’m simply too used to spinning up plain old Team Sites, which still serve their purpose well. A Team Site with a Document Library, Task list, and Calendar, is often enough to manage a SharePoint project, with other options added along the way. (See my older posts Simple Best Practices for Using SharePoint Task Lists and Recent Changes to Task Management Conventions on Office 365 for how I tend to use the Task lists.)

Office 365 Groups are really cool (they definitely didn’t strike me that way early on) and they make a lot of sense for project-based work. Because of the tight integration with Exchange (most important to end users via Outlook) and other Office 365 services, they really do make a lot of sense.

But the last point is what I want to dwell on most here.

One of the best – and to some people, worst – things about Office 365 Groups is that pretty much anyone can create them. You can shut things down to gain control, but then you lose the value of people spinning up a group whenever they need one to be productive. Your organization’s culture and governance will determine which way you go with this.

Let’s assume you keep things loose. Each time someone creates a new Group, they sort of “burn” the name they use for the group. Remember that creating a Group does a whole bunch of things behind the scenes that can’t realistically be “undone”, like creating a Site Collection for the Group, creating an Exchange mailbox for the Group, etc. This means we can run into all sorts of weird scenarios. For instance…

  • A couple of people could be going to a conference about marketing, so they create a Group called Marketing. Now the Marketing department can’t create a Group called “Marketing”.
  • We have a company meeting every year called the Extravaganza for the Company, so we create a group called EC so it’s simple to type. Now the Executive Committee can’t use that “handle”.
  • In the conversation above, Sue and I settled on the “short name” for the URL of IP2017. That’ great unless there’s a rotating Intellectual Property committee that starts work anew each year.
  • etc.

It’s not quite this cut and dried, but I’m exaggerating the problem a little bit to keep your attention.

A little planning can go a long way here. While you probably want to let people have the flexibility to create their own groups. making a few simple guidelines clear should avoid a lot of headaches down the road. Yup, another place where the dread governance word comes into play.

When you create a Group, there are two things to think about: the Group Name and the Group ID. The Group name can be changed at any time, but the Group ID cannot. Below, you can see that as I’ve typed the Group Name as testing, the Group ID has automatically been populated as testing as well. You get a hint of the significance of the Group ID because the email address the mailbox for the Group will get is listed in green below. (It’s a pretty yucky green, IMO.)

If you click on the pencil icon next to the Group ID field, you can edit the value. You’ll see the change to the email address as you type. As you type each character, there’s also a check to see if that Group ID is in use already. This is where things can get interesting.

In the screenshot below, you can see that when I type moderngroup, that Group ID has already been used. My example isn’t great, because I would be unlikely to want the URL to be moderngroup for a Group named testing, but hopefully you can see the point.

If you create the Group in the Admin interface, the UI is a bit different (Why, Microsoft???) but the result is the same: if the Group Id (note the different capitalization) has already been used, you can’t use it again.

So how can you keep things from going “off the rails”?

Odds are you’ll know about a big bunch of Groups you’ll need up front. For instance, if you want to create a group per customer team, you could use the customer number for the Group ID (12345) and then the Group could be named something like Big Realty Company (12345) or 12345 – Big Realty Company. You’d certainly want to create Groups for your departments and offices up front to reserve those names, etc.

So while there aren’t any hard and fast rules here, make sure you do some thinking about it. One of the reasons SharePoint became popular in the early days was that it grew like kudzu across the organization – it started out great, but things usually got out of hand. I feel that Groups may take the same path – and in early adopter organizations probably already have – without some rational thinking on the part of the planners in each organization.

Do you have a useful way for people in your organization to think about naming Groups? If so, please add a comment!

References

Similar Posts

10 Comments

  1. I think this is a really important point about naming and could see combining governance with customization for the “approved” way to create groups. By customizing a UI that creates the group for the user and asks more questions to help guide the naming structure you could create a really powerful solution.

    1. Great point, @Julie. Until Microsoft makes a better process for Group creation (which I have to believe they will), fronting the process would be great. Unfortunately, there are too many entry points to “plug all the holes”: Outlook, Teams, SharePoint home, etc. I fear many people will simply disable Group creation because the administrative tools are still too weak.

      M.

      M.

      1. I would wonder if maybe disabling group creation could be “gotten around” by custom code through MSGraphAPI… not sure how “disabling” it works so that’s just a shot in the dark.

    1. @Marcel:

      That’s a simple one. Teams *are* Groups under the covers; when you create a Team, you get a Group. The different names are due to – as @jthake likes to say – Microsoft “shipping their org chart”.

      The question is whether you want to use the Teams app for your social networking tool. You could also choose to use Yammer which would preclude you from using Teams. You can only choose one.

      M.

  2. It’s very easy to cause big problems here. I created a group for myself and a couple of others called Northeast-sales. Unfortunately, that was very similar to an existing distribution list and the sales manager kept sending his messages there, not realizing that they weren’t reaching his intended audience.

    1. @Ruven:

      While this has been the case with distribution lists forever, you raise another great point. I don’t know that many organizations have been great at naming things over the years, and this new Groups concept has to merge into the existing thicket.

      People may well just start doing things like “[email protected]” because someone created “[email protected]” years ago – whether it was used or not – because going through the IT gauntlet may not seem worth it.

      Warning to IT everywhere : Yet Another Reason to get a very strong customer service mindset.

      M.

  3. Great article Mark!

    I hit the same thing here as O365 Groups, Planner and Teams each came out, as they (Planner and Teams) create O365 Groups, which creates site collections.

    I’ve tried using the Group naming rules (Exchange Online), which allows you to add prefixes and suffixes to groups – but unfortunately it’s never worked consistently with O365 Groups (seems OK with distribution groups and possibly security groups).

    So I’ve had to lock-down Group creation :(

    Instead, I’m working through a context based prefixing. So tst- for testing related sites, prj- for project related sites, clt- for client centric sites, etc. It wont fix all situations, but I’m hoping it will help.

    Maybe, one day, MS will give us more than just /sites and /teams to work with (/portal used to work too).

    Given the globally acknowledged significance of Governance around SharePoint (both on-prem and Online), it’s a real pain that first O365 Groups, then Planner and then Teams, all broke the Governance model. Yes, giving end-users the freedom to create Groups/Plans/Teams is wonderful (for them), but it’s just taking us back to the Wild West, that SP Admins have been working hard to avoid for many years now.

    BTW one of the things I’ve done to help manage O365 Groups, is a powershell script to enumerate them (they don’t appear in Get-SPSite) and assign a security group (SPOnline Admins) to be site collection owners. This means I can then access the traditional user/group pages (via URL, since they’re not in the menus) and manage permissions. It also means I now have scriptable access to those sites.

    Thanks
    Craig

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.