Reconciling Changes While Moving Content in SharePoint – “Flat” Views

Lots of times when I’m working on a content migration in SharePoint – almost always with Sharegate! – some stuff happens. Probably the most common thing is that someone edits content in the old location before we manage to shut off permissions. People – yeesh!

Here’s a little trick that not a lot of people know about that can really help. As we all know, folders are bad except when they aren’t. Oftentimes, Document Libraries have a lot of folders containing a lot of documents, for better or worse. If you want to hunt down documents someone has changed during a migration, you can set up a “flat” view, sort by Modified (descending) and see what they have been up to.

Here’s how…

Go into Library settings (how you get here will vary based on SharePoint version) and create a Standard view – or more likely start with one of the existing views, like All documents.

Give your view a name (I like Temp – because I’m probably going to delete it), scroll down to the Folders section, and expand it. Click on the Show all items without folders radio button and save your view.

Now you’ll see ALL the documents in a “flat” view (assuming you don’t have any filters set). You can add/remove any columns in the view, but the key thing here is you can sort ALL documents by things like Modified date (descending) in the UI to look for stragglers.

Advertisements

Office 365 Groups: Let People Outside the Organization Email the Group

As a consultant, on a daily basis I’m working in multiple Office 365 tenants. In some of those tenants I have an account (license) with my own Sympraxis email, and in many others, I have an email address within the client organization’s domain.

Believe me, it all gets pretty confusing – if it weren’t for LastPass keeping track of my logins, I’d be doomed!

With all the Office 365 Groups goodness going on, it’s great to try to keep track of “Group conversations” in a central place. By including the email alias for a Group in email-based exchanges, we can save those conversations for posterity.

Given the complexity of my account setup across clients (let me know if you have suggestions on how to make that easier!), it’s really helpful for me to use my Sympraxis email account to centralize *my* conversation activity, at least.

To do this in a given Office 365 Group, you can change the Let people outside the organization email the group setting for the Group, as shown below. This allows me to be a member of the group with whatever account I have in that tenant, but also to email in with my Sympraxis account.

In theory, this opens up your Group conversation to “spam” or other unwanted outside emails. In practice, it’s probably not a problem, especially for a Group which has a relatively limited lifespan. You’ll probably want to consider which Groups really need this setting enabled.

In any case, it was a little tricky to find the setting after the Group was set up, so I figured I’d share.

  • If you’re in the SharePoint site for the Group, Go to Group conversations (link in the upper right)
  • This takes you to the Outlook-in-a-browser view of the Group
  • In the upper right of the screen, click on the ellipses (…)

  • Click on Edit group

 

Now, if I could only choose the color for the Group! I’m sure that setting is somewhere, too. Any ideas?

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.

</UPDATE>

The Arctic SharePoint Challenge: A Hackathon for Office 365 Enthusiasts

This is an expanded version of the article I wrote for BZ Media‘s SPTechReport – the folks who bring you SPTechCon – last week. (Use my code ANDERSON when you register for SPTechCon Austin and save an additional $200!)

Last week I had the honor of being a judge at the Arctic SharePoint Challenge in Oslo, Norway. This is an annual challenge put on by a group of SharePoint-focused consulting companies in and around Oslo, though occasionally teams come from further afield.

Each year, there is a different theme. Two years ago when I was a judge the first time, the theme was Star Wars (apt, given the Hoth-like landscape outside the hotel where ASPC is held), last year was Marvel, and this year was The Matrix.

The Mission: #ASPC2017 aims to stimulate collaborative learning, networking and stimulation of ideas for participants through hands-on, time-limited challenges. We are fiercely competitive, yet vastly helpful and extremely sharing (also across teams), realizing that collective learning is more important than personal gain!

More informally, I see several great outcomes of the challenge.

  • Demonstrate, use, and learn about the latest developments in the SharePoint ecosystem
  • Work together in teams that – though generally from the same company – may rarely get to work together. (On site client work keeps them separated much of the time.)
  • Step outside a normal comfort zone, outside a client context, and try some crazy stuff.
  • Meet and work with teams from other consulting companies in the region.
  • Have a truly great time.

The challenge is held at a beautiful hotel in the mountains outside Oslo. When it’s raining in the city, it’s usually snowing near the hotel. It’s a great facility with fantastic food – no cold pizza for this hackathon.

View from the bridge of the Nebuchadnezzar – courtesy David Parker – Tap or click to see the 3D version at Theta

So, we had all the ingredients for a great event:

  • Smart, motivated people
  • Fantastic facilities
  • Judges from far away (we get the best deal, I think!). Joining me for the judging were: Benjamin Niaulin (Sharegate), Fabian Williams (K2), Yina Arenas (Microsoft), Scott Durow (Develop1), and David Walker (BVisual).

Each team decides what to build, with some connection (sometimes rather obscure) to the theme. The theme makes the event a lot more fun, and provides many opportunities for movie line quotes and strange scenarios.

We had a predefined list of categories upon which to judge each team’s work.

  1. Awesome Code–  Best practice around different technologies; What type of framework; BP on Platform chosen; Having a GitHub Repo; Nice Code / Commit / Issues // Commented
  2. Go with the Flow– Workflow automation; Webhooks; Forms and process automation; Event receivers; CRM workflows
  3. User Experience– User friendly, Usability, User interaction, Accessibility; Mobile; Responsive design
  4. Geeky Bastards– Use iOT and other tech outside of O365 area; Mention Azure ML; Python or R; Bot Framework; Hololens; Tesla; AI, Cortana, Alexa, etc
  5. Power User Love– Your solution can easily be extended or used by “Power Users” to do more with it.
  6. Mile High Club– Cloud services; Azure functions; Microsoft Graph; AWS, Lambda; Cloud APIs
  7. Team Spirit– Open your code so others can use it; Be a good team; Happy camper; Help others; Blogs sharing what you have learned
  8. Dynamics Dynamite– Use of Dynamics 365 in the solution. This was a new area for many of the teams, but a few found some CRM experts to bring along with them.

Bonus Challenge – Visio – Develop custom shapes, connect them to data, and embed them in SharePoint. Hint: There’s some great new stuff coming here very soon, so keep an eye out for an announcement! We got a bit of a preview as part of the challenge, and it’s not your grandfather’s Visio anymore. (Did you know Visio first came out in 1991?)

Scott Durow did a yeoman’s job of keeping score during the event using Dynamics 365 to capture the data as we went along, and Power BI to display it. If you click on the image below, you can see the final, live scoreboard.

As you can see, the PuzzlePart Appsters took the competition this year. I believe that makes it 3 / 7 for them. If you’d like to see some of what they were able to build, take a look at the Team Blogs on the ASPC site. The Appsters’ intro video for the final presentation is over on YouTube:

I’d love to see this hackathon / challenge idea reproduced elsewhere. I’ve been to several other hackathons as a judge, and this one has something special going for it. The combination of factors: great location, company-based teams, entertaining theme, and admirable goals truly makes for something special that people return to year after year.

It’s very interesting and important to have events like these, made me realize how little I know. A perfect time to step out of the comfort zone and the work routine to explore ideas with like-minded folks in the industry. Seeing Bots interact with the Microsoft Graph, Hololens recognizing faces and storing the information in SharePoint, integrating Flows and PowerApps to CRM and our beloved platform…very exciting and more importantly, a great learning experience – Benjamin Niaulin

Reports from afield tell us that SharePoint user group participation has flagged (at least in the US). Perhaps events like these are the next evolution of the “user group” concept?

If you’d like to know more about ASPC so you could try to run a similar event, feel free to ping me and I can put you in touch with the appropriate person. Also, it would be great to see a few new teams at ASPC 2018!

Additional Information

David Parker’s posts

Some particularly tricky problems solved:

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