More Granular Permissions for Office 365 Groups: A Work in Progress?

There are changes afoot in the way we can manage permissions in an Office 365 Group Team Site. (Naming for this stuff is getting really tricky. I continue my habit of capitalizing “things” that have a name in the product, to avoid confusion with the “concepts” behind them.)

In the last few days, we’re seeing some new ways to manage Group permissions behind the cog in a “modern” Team Site, aka, the site for an Office 365 Group.

Dan Holme (@danholme) posted an image to Facebook – which I think is visible to his friends, thus basically public – that shows his view of what’s going on.

I see slightly different things in several tenants. I *think* First Release has to be on for you to have these capabilities, but I’m not positive about this. If you have the Site Permissions option behind the cog in a “modern” Team Site, like this…

…you’ll see a panel which looks something like the one below. The red box is what seems to be new. From a Group Team Site life cycle management perspective, being able to “flip” a site from Edit to Read mode is a Very Good Thing. I’m not a huge fan of the “archive” idea, but I often want to stop people from using a site after it’s usefulness has waned. At that point it can be an historical record, but people shouldn’t be able to add new content to it or change existing content.

It took me some fiddling around to figure out how this works, but by clicking on the “Edit” underneath the Group members, I can change the permissions from Edit to Read.

The effect of this is basically to slide the Group members down into the Read bucket.

What I’d really like to be able to do is add *different* people into the Read bucket – maybe we want the executives to be able to drop into a project Team Site, but not edit stuff, for example – but I can’t figure out how to do that with the UI as it is. Note that the “go to Outlook” text at the top of the panel is actually a link (sort of invisible, but it’s there) to take you over to Outlook to manage Group membership. I don’t see anything over in Outlook which reflects this Read idea, but I expect that’s coming.

One of the joys of a living and breathing service is we get to see things as they roll out, sometimes even in the middle of changes. I expect this will all gel in the near term, but at the moment, it’s pretty confusing, IMO. I’ve reached out to Dan to gather more info, and I’ll add it here as I understand things better. In the meantime, we know that more granular permissions control for Groups is really coming!

Advertisements

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

Dear Microsoft: I’m Confused. Can You Help Me Collaborate Well?

Yup, I’ll admit it: I’m confused.

The launch of Microsoft Teams last week is what’s done it. First of all, from everything I’ve seen of the new tool, it’s really cool. I had some trouble getting my head around how to get it up and running in our Sympraxis Office 365 tenant, but now Julie (@jfj1997) and I are taking it for a spin and we like it.

Microsoft Teams

What’s confusing to me is where Microsoft Teams fits into the spectrum of similar offerings, which all look pretty much the same to me on many levels. We have Yammer, Group Conversations, Microsoft Teams, email, Team Site Discussions, and the old SharePoint newsfeed. Now, I’ll allow that the last two are pretty much obsolete, but they are still in the UIs and people see them. This is a lot of choices.

Every time Microsoft comes out with a new “social” tool set, the rhetoric around its positioning tends to be “Hey, we think you like choices, and here’s another choice for you!” It’s absolutely true that everyone works differently, but there are patterns in those different ways of working. While we all may be special flowers (see my comments about millennials below), but we aren’t snowflakes; there is a lot of similarity in the types of things we are trying to solve in our collaborations.

I wish I could find the old slides we used to use when I worked in Renaissance Solutions back in the late 1990s, but I think they have been lost to the electrons of time. When we talked about the different communications mechanisms that we available for people to use for good knowledge management, we listed out 6-8 methods. We talked about them being part of a portfolio of options, each of which had specific set of good use cases. (Some of the terminology has changed, but the ideas haven’t changed all that much.)

For instance, you shouldn’t fire someone over email because it’s an emotional event; that deserves and in-person meeting (generally one-on-one). You also shouldn’t call an all hands company meeting if you’re just reviewing a task checklist if an electronic sharing mechanism works just as well. And so on. These common sense rules are broken all the time, but that doesn’t mean they don’t make simple senss. It’s often simply that no one has provided enough guidance on how to think about things.

One of the big issues I see in our overly connected world these days is misuse of the various options we have at hand. One example is Microsoft support calling me on the phone when I’ve created a support ticket via the Web; generally we should stick to one modality and not shift mid-stream. Like it or not, the initiator gets to choose, and we should only switch by mutual agreement. (“Would you mind if I emailed you some more details?” in a conversation, for instance.) Sometimes my wife and I have this problem, too. We might start a conversation in a text, it jumps over to email, and then becomes a note on the counter. That jumping between methods waters down the interaction and makes it far more confusing. One of the methods was probably the right one, but we’ve subverted that.

What has me confused about Microsoft’s overlapping offerings in the communication spectrum is that they don’t come with guidance about which is good when or for what type of organizations. Instead we see a lot of talk about choice being good. Choice seems good, but when you get right down to it, open choice leads to a certain amount of chaos. Many people I talk to would like some sort of help understanding what Microsoft is thinking, at least, but Microsoft seems unwilling to do this.

When Microsoft is working on the development of a new tool like Microsoft Teams or adding enhancements to an older tool set like Yammer, they must have use cases in mind. (I truly hope this is the case, and I believe it has to be!) But those use cases don’t really make it out to us in the form of helpful portfolio management strategies.

One standard Microsoft answer to things like this is that it’s a “partner opportunity”. That would be an excellent answer if every partner understood how to do this type of positioning, but many don’t. Many partners are technical partners and focus far more on implementing the hardware and software (nay, services). This isn’t a bad thing, it’s just the way it works.

As a consultant who has done a lot of knowledge management work and collaboration and strategy work after that, I suppose I could look at this as an excellent opportunity for me to go out and make a lot of money advising clients about how to manage all of these options. That might be good for me (and hopefully for my clients), but it doesn’t help the ecosystem all that much.

Another chestnut that we hear a lot is “Well, millennial want something different, so…” This is a weird one to me. Sure, younger people may be different, but remember we’re all special flowers, right? People entering the workplace don’t know how to do things in the workplace yet. Simply catering to them – it certainly didn’t happen back when I started working – will just water down effective work styles developed over years. Don’t get me wrong: a lot of work methods are just plain dumb and should be questions, but mindfully and not just because the kids don’t like them.

When I look at the graph below from Avanade, I see some really interesting information. But I also see that many people I know in my generation (I’m a Baby Boomer!)  must be doing things wrong; we don’t act like the stats. I also know millennials who don’t act like millennials. And my son isn’t just like his Gen Z group, either. When I interact with any of these groups, I need to adapt my methods based on what will work at the time, not just what *I* like.

Statistics like this are absolutely useful, but you need to understand your own organization to know what will work. If it’s an organization with lots of closed offices and hierarchy, it’s different from one with an open office plan and a lot of cross-functional work. Age usually has little impact on those constructs. So when you think about what will work for your organization, wouldn’t it be great to have some sort of framework from which to make decisions? A sort of “portfolio management” approach?

I’m reminded of the great work Sadie Van Buren (@sadalit) did a few years ago on her SharePoint Maturity Model. It gave people some very clear ways to think about where they were on the spectrum of success with the platform. The model is a little dusty at this point, but it still makes a lot of sense and can help drive decision-making. (If you check it out and think it’s still useful, please let Sadie or me know. I think it needs a renaissance for Office 365!)

So how can Microsoft un-confuse me, and by extension many of you? Well, I think they need to put their internal politics aside and draw some lines in the sand. For example, regardless how you feel about it, Yammer is good for interactions that require external users because many of the other options don’t provide that capability. A simple statement like that can make some decisions pretty simple: You need external users; you need Yammer. QED. But you rarely see Microsoft making such a clear statement.

Here’s hoping that the smart people in Redmond get on this soon. As the options keep piling up on us, it’s only getting harder to choose. If I were a betting man, I’d pick some winners and loser in this game, too. Knowing what makes sense for specific use cases would reduce risk for organizations who need to make choices and stick with them. Change in most organizations is hard – and expensive. Making good decisions based on good guidance up front makes those changes far more palatable.


nb: I”m publishing this from the plane on the way to Microsoft MVP Summit. It’s best to get this off my chest before I get all jazzed up this week! Maybe I’ll be able to convince some people about this stuff while I’m there.