Column Formatting in SharePoint Online Rolling Out!

Every once in a while, something comes to Office 365 where no one has anything negative to say. (Is that a back-handed complement?)

The fact that this tweet got 22 retweets and 34 likes (as of this writing) and lots of eyeballs means this is one of those things.

Over the years we’ve had several ways to change the look of a column in a list view. Early on – say in the SharePoint 2007 and 2010 days – we often used jQuery in the page to do what we needed. This was WAY before it was fashionable to write client side code for SharePoint. It worked just fine, but had pretty decent barriers to entry. You had to know how to write JavaScript, get it into the page, use CSS3-like selectors in jQuery, etc.

In SharePoint 2013, we got something called jsLink, which was part of what most people refer to as Client Side Rendering, or CSR. This was a pretty good mechanism, and also used JavaScript, but with some fairly arcane functions and structure. However, it allowed us to customize both individual fields and entire rows.

Announced at Ignite, we now are getting a new capability to format columns in “modern” list views. It doesn’t seem to have a snazzy name other than “Column Formatting“, but that doesn’t matter.

There’s a great page with documentation and examples which we can tweak to get what we need: Use column formatting to customize SharePoint. This new mechanisms use what’s called declarative customization, meaning we don’t actually write code – though it may feel like code to many of you. Rather than code, we write JSON, which stands for JavaScript Object Notation. JSON is basically a way to store data.

Let’s look at one of the examples from that page.

Say we want to color a column’s value if that value is less than 70. (The text on the page says color it red, but the little image is yellow, so I’m not sure they have it right at the moment – especially since the number is exactly 70.)

In any case, the JSON data below says the following:

If @currentField < 70 Then add the CSS class = sp-field-severity–warning.

which gives us something like this (with the above caveat):

While the techies will tell you this isn’t code, it really sort of is. The condition we want to apply is stored as JSON – which is data – but tells SharePoint how to render the field. The fact that we use operators, operands, etc. to make this happen means that we are effectively writing code. That said, I expect we will see a great number of “recipes” arise out in the community, just like we did with the great SPCSR repo in Github. In fact, I challenge all of you to start sharing your recipes as soon as you start using this feature!

As soon as we can all get our hands on this new capability (watch for it in First Release by the end of October), I expect to start adding examples to a new Github repo I just created: SPColumnFormatting. If you don’t understand Github, don’t fret. You’ll be able to just copy the recipes and alter them to meet your needs. If you do understand Github and would like to contribute, please do with a pull request. The faster we build up a set of recipes people can use, the more productive the citizen developer army out there will be!


Want to Get a Look at the New Communication Sites? Here’s a Trick!

If you’re like me, words can be confusing. When Andy Haon (@AndyHaon) tweeted that Communication sites were starting to roll out, I wanted to get a look. However, I didn’t see the option in my First Release tenant. I wondered what “Select Users” meant and whether I wasn’t one somehow.

Luckily for me, Twitter is really useful for stuff like this. Rick de Vries (@RickdeVries) pointed out that there a two “flavors” of First Release – First release for everyone and First release for selected users.

By switching my tenant so that Julie (@jfj1997) and I are “selected users” instead of just having the tenant-wide setting, we can now see the option to create Communication sites.

Here’s how you do this, assuming you have administrative permissions.

Got to the Admin center and click on Settings / Organizational profile / Release preferences. There you’ll see the two different First Release options:

For more information, check out Set up the Standard or First Release options in Office 365. I couldn’t figure out how to get the UI to add individual users to work, so I ended up uploading a csv file with our two email addresses. #YMMV Note that it took at least a few hours (possibly overnight) for me to see the Communication site option.

Et voila! We can now create Communication sites from the SharePoint home page.

Beware the Office 365 Group -Based Site Regional Settings!!!

This is a quick post, yet it’s still an important one. We’re using more and more Office 365 Group -based SharePoint sites these days. Even when you know you aren’t going to use some of the goodies you end up with, this type of site is making more and more sense.

<addendum data-datetime=”Sun May 14 2017 10:56:53 GMT-0400 (Eastern Daylight Time)”>
Several people have asked me in other forums the basic question: “So what?” If all dates and times are stored in UTC, does it really matter what the site’s Regional Settings are? Frankly, that’s got me a little bit stumped.

It certainly feels wrong that the site’s settings don’t match its primary locus, but since team members can span the globe, what’s the impact?

I know I struggle as a developer to show everyone things in the right date/time based on their settings, and it feels like the platform doesn’t give us great tools for this. What other issues does it raise? Please add your thoughts and issues in the comments. I’m interested in things other than the usual “The people in Redmond don’t realize that we’re not all in their timezone” stuff – which is basically all I’ve pointed out here.

BUT, there’s a simple problem that can have longer-term ramifications. The default time zone for every new Group-based site we create is PDT, also known as UTC-08:00. You have to go into Site Settings to change it manually for every site you create this way. Since a lot of my clients are in EDT, this is tedious.

I’m guessing no one in Redmond even notices this, because PDT is their time zone. I spot it every time I create a new Group-based site during a migration because Sharegate warns me the time zones of the source and destination sites are different when I start to copy content across. (Yay, Sharegate!)

If you happen to be a non-US person, then ALL of the regional settings are likely to be wrong for you. I’ve checked, and there is no way to change the default here – unless it’s a VERY recent change.

Here are some Office 365 UserVoice suggestions you can run off to vote for:


Dear Microsoft: In Office 365, Groups are Groups are Groups – Unless They Aren’t

One of the problems with using common English words for things like “groups” or “teams” is that we end up trying to figure out the difference between things with very common names. When Sue Hanley (@susanhanley) and I were building our session Lions and Tigers and Teams, Oh My! – Sorting through the options to connect and collaborate in Office 365 for SPTechCon Austin recently, I realized just how confusing this could be – yet again.

The Problem

On the SharePoint home UI, when I want to create a “group”, I am told I will “Get a team site connected to Office 365 Groups”. So based on that one sentence, I might quite reasonably assume I’m creating a “Team” and a “Group” – which it so happens I am – sort of.

In the Groups UI in the Admin Center, we see these options:

  • Office 365 Group
  • Distribution list
  • Mail-enabled security group
  • Security group

In the Exchange admin center when we start to create a “group”, we’re given these choices:

  • Office 365 Group
  • Distribution group
  • Security group
  • Dynamic distribution group

But don’t fret. When you go to create a “group” in the Azure AD UI, you can create a “group” with Membership type of:

  • Assigned
  • Dynamic Device
  • Dynamic user

We can also check a box to “

Selecting ‘Yes’ will turn on Office 365 features for this group

I can even try to add the “group” – it’s not clear which type of “group” I’ve actually created – to the membership of another “group”. “Group Type” seems to be one of the following:

  • Distribution
  • Security
  • Office
  • Mail enabled security

When I create a Team in Microsoft Teams, there’s not even a clue that I’m also creating an Office 365 Group behind the scenes. Maybe that doesn’t really matter to an end user, but the fact that a “Team” is also a “Group” is another terminology SNAFU.

So What?

Some people might say that as an “IT Pro”, one should always understand all of these terms intrinsically, but I doubt that it’s often the case that this is true. The terms cross different “workloads” in Office 365 and can vary in terminology from their on premises counterparts, especially across server versions. Add to that the fact that many “admins” are the lone SharePoint/Exchange/Office 365/Chief Cook/Bottle Washer in their organization, and there is little hope they will understand the nuances. Heck, I do this stuff for a living and I find it confusing. Sometimes things are hard for no good reason.

Let’s assume we have an organization which is totally sold on the value of Office 365 Groups (note the capitalization of “groups”). If they have been using SharePoint and Exchange either on premises or in Office 365, they probably already have a mix of all the different types of “groups” shown above. When someone in that organization tries to create an Office 365 Group for – say – the Executive Team, it’s highly likely they will get an error like:

Note that “group alias” is not one of the terms used above, nor does the error give even an inkling of how to solve the problem. Not even a worthless “Contact your administrator” as a fine how-do-you-do. So, what is the user likely to do?

Well, I’ll posit that they will create a Group named “Executive Group” or “Executives” or something else spelled a little differently. That Group won’t be linked to any of the previous artifacts and thus will begin the route to more chaos that we had before.

Of course, this is a real use case I’ve run into at an actual client, as is often the case with my beefs. As far as I can tell, there is no way to convert a “Mail-enabled security group” to an “Office 365 group” without some sort of Powershell tomfoolery. That’s just bad. I’ve reached out to my MVP network for help here and I’ll update this post if I’m wrong – and I’d love to be.

This is where the old Microsoft line would have been that it’s a great “partner opportunity” or that there are “$9 spent in consulting for every $1 spent on server products”. Those were always crappy answers, and they were often driven by confusing things just like this. The “avoid a mess” or “clean up the mess” roles fell to partners who were more than happy to lap up the dollars agonized organizations were willing to toss them to fix things.

The new Microsoft doesn’t want to work this way, but in many cases, their own large size and competing teams (small “t”, generic use) still lead us to these sorts of problems.

One of the things we as consultants spend a *lot* of time doing is working with organizations to build a common set of terminology. Sometimes you may hear this called taxonomy or ontology, but the bottom line point is to get everyone to agree to a set of words and phrases that they can use consistently to express the same thing. If I came out of one of those efforts with as many terms as I’ve listed above, I’d consider the effort a failure, especially if several terms meant essentially the same thing.

The Ask

So, Dear Microsoft, please tighten up the terminology as quickly as you can. Next we need to know how to convert each of the old, legacy types of “groups” to an Office 365 Group – without resorting to Powershell. Ideally, we should just be able to click a button on any of the old things to make it a new thing, which would take us through a process (if we need one) to get it done.

Even better, when I try to create that Executive Team Office 365 Group, walk me – as a user – through fixing the issue. In other words, help me solve the problem BEFORE I’ve created the mess, so I don’t need to call a consultant to fix things. (Yes, nose, face, etc., but I think most of us consultants would rather be building valuable functionality than cleaning up messes. If your consultants relish this type of work – beware.)

Make it easy for us to help ourselves. Cut down on those support calls. Stop making your customers hire expensive consultants to clean up messes. Make Office 365 the best it can be.

Post 999! Sadly, I may have just used up my allotment of quote characters for any future posts.

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!

<UPDATE 2017-03-03>

Yesterday I had a chat with Dan about where this is all heading. It was one of those “I can’t tell you what he showed me” conversations, but I can say that I see the sense in where it’s heading.

It’s a tricky line they are walking as they move SharePoint from “classic” to “modern” pages. Many of us long-time SharePoint folks are looking for the same terminology and UI that we’re used to – even though we’ve been clamoring for improvements for years!

The upshot is I think we will have the right combination of the old SharePoint (that’s probably why we see “Site Members/Owners/Visitors” in the UI above) and the “modern” SharePoint (probably more role-based?). It’s going to continue to feel weird as we move from one world to the other, but we’re getting there.

Finally, Dan and I talked about a few things I think they could communicate a bit better. I expect Dan and others will be doing posts around some of those topics (did you know you can remove the News Web Part from a “modern” Team Site home page now?) and more very soon.