Wednesday, February 22, 2017

I’m late to the party again, but so the is the “Create site” UI

I want full control over sites and Office 365 group creation and I’ve seen the setting in SharePoint Online Admin for ages to specify my own form URL. My bad for not testing this earlier.

image

Well, turns out, this does not replace the default form, which still allows me to create an Office 365 group off the, but instead adds a tiny tiny link on that form which no one will ever click.

image

Seriously? Which leaves the only option left, hide the “Create site” link altogether, and tell users to go to my fab order form instead.

Tuesday, February 21, 2017

All you never wanted to know about Exchange Online, Azure AD and Office 365 Groups creation

Before setting the scenario, the solution to my problem would be either an Office 365 group with dynamic Azure Active Directory membership where all services in the Office 365 group where opt-in and not mandatory, or an e-mail enabled security group with dynamic membership. Neither of those options exist and we ended up having one dynamic distribution group and one dynamic security group.
image

Tuesday, February 14, 2017

Microsoft Flow, the lazy coder’s alternative to SharePoint web hooks

image
SharePoint web hooks has made it out from preview and into general availability, and is a great way for applications to act on changes to items in SharePoint. Think workflows where you want to run custom business logic when someone creates or edits an item. For the old-timers a web hook is just a new type of event receiver on the created/updated/deleted events.

The good thing about web hooks is that you can tack them on using either an Microsoft Azure Active Directory application or a SharePoint add-in, using application credentials. This of course is the proper way to do it, so if you are coder-proper, then stop reading now.

So why do it the lazy way using Microsoft Flow?

If you go the route of creating a web hook programmatically you have some plumbing to do up front:
  • Get an administrator to register your AAD app or SharePoint add-in
  • Write code to subscribe the web hook to events on the list/library
  • Write code to re-new the web hook subscription once it expires (max 6 months)
  • Write code to fetch the data of the item which triggered the event
The lazy approach is somewhat a smoother ride, and is what I used at a recent hackathon to get things working fast. The drawback is that Microsoft Flow runs in user context, so you only get events on items you or the account you used to authorize a particular connection have access to – but this might work our just fine for many scenarios. Using a service account is one possibility.

If all you want is access to the data of a created/modified item and want to pass it to a custom API, then using Microsoft Flow makes it very easy. One trigger action which return data for all item fields, and one HTTP action (with swagger if you fancy that) to your custom API with a payload of your choice and you’re set. You can focus purely on the API logic and let Microsoft Flow handle the eventing for you. If you want to handle both created and modified items you need to create two flows.

image

I'll be fair and say that Microsoft Flow currently does not handle everything and come with some caveats.
  • Currently no support for updating taxonomy field
  • Currently no support for updating lookup fields
  • Currently no support for updating choice fields
  • Currently no support for updating people fields
  • Updated items will have “you” or the account used in the connection to SharePoint as the last modified user
  • Updating a list with more than 12 lookup/taxonomy columns will report as failed, even though they work
As you can see, the weak points for now are on updating items, not getting the values of the item itself - so happy flowing!

Tuesday, February 7, 2017

How to consent to an Office 365 service app

At times you might want to create services which interact with the Microsoft Graph or Office 365 API’s.

If your application has an actual web page you will get prompted for consent when you visit and login. If you have elevated privileges you would tack on &prompt=admin_consent to the URL and then your service can authenticate and do what you need it to.



If you create an Office 365 application entry in Azure AD and have no web application tied to it, this is not automatic.

One approach to get the consent URL is to create a small c# app using the ADAL libraries.

string ResourceId = "https://graph.microsoft.com"; // Microsoft Graph End-point
Uri RedirectUri = new Uri("[APP ID URI]");
ClientId = "[O365 App ClientId]";
ClientSecret = "[O365 App ClientSecret]";

var authenticationContext = new AuthenticationContext("https://login.windows.net/common/");
var url = await authenticationContext.GetAuthorizationRequestUrlAsync(ResourceId, ClientId, RedirectUri, UserIdentifier.AnyUser, "prompt=admin_consent");
Console.WriteLine(url);

If you have a multi-tenant app, you have to login to each tenant using the outputted URL to consent per tenant.

Monday, February 6, 2017

Gaps and differences between a Group 365 Modern Team Site and a plain old Team Site

This post outlines some of the differences between an Office 365 Group Modern Team Site and a plain old SharePoint Team Site as of February 7th 2017.

[Updated to match the GA announcement February 23rd 2017]

The gaps may or may not affect you, but from a document management perspective we keep hitting several of the differences in every single projects which often leads to falling back to a plain old Team Site.

As there has been talks of enrolling/upgrading plain old Team Sites into a modern site in a group, I hope the limitations will go away and align more in the future. At Puzzlepart we see the most important ones being able to programmatically configure up pages in a scalable way and having access to synchronized content types.

image