Self-service Microsoft Form for external guests to use Power App

/

This is a walk through of the steps to create a self-service guest user sign up using Microsoft Forms and redirects to the Power App.

Steps

  • Create a Microsoft Form to capture external user’s email address

  • Create the app registration to be able to make a Microsoft Graph invitation call

  • Use Power Automate via Microsoft Graph invitation API to add this email as external user to tenant

  • Add user to a group that the app is shared with

  • Redirect back to the Power App (or SharePoint extranet site, or Teams)

Create Microsoft Form

  • Change setting to allow anonymous - anyone can access this if they go to the form’s public shared URL

Create App Registration in Azure AD Portal

  • Go to Azure AD portal > App registration

  • You should name this app similar to your Power App name - it doesn’t need to be the same, but it’s less confusing to your tenant admins when reviewing the registered apps in Azure Portal.

  • As this app registration is only used for your tenant - it can be Single Tenant

  • Add Application Permission for User.Invite.All

  • This is a tenant admin consent required permission, so grant it here, or ask a tenant admin to grant it.

  • You will need to generate a Client Secret (no screen shot included), save that client secret.

  • You will also need to copy the Client ID

  • You will also need to copy the Directory ID (tenant ID)

Oh we need a Power App

  • Made a quick Power App here - the text label shows the current user’s email. For external user this would show external email (to proof this works).

  • For Sharing - I’ve made this Power App shared with Everyone.

  • We need to copy the Web link with the tenant-id

Now we need a Power Automate (Flow)

  • Run on Microsoft Form submission

  • We’ll need this redirect URL - when external guest invite is complete, redirect to our Power App

  • Because we registered an “Application Permission”, we can use the HTTP action to call Microsoft Graph without using delegate permission.

  • See also https://docs.microsoft.com/en-us/graph/api/invitation-post?view=graph-rest-1.0&tabs=http

  • Enter: Tenant, Audience, Client ID, Client Secret (not included in picture)

  • You should have all these values by this point.

  • The JSON message to send to Microsoft Graph should have the redirect URL back to the Power App

  • If successful we will get a user Object ID - we should add this to a Group as you need.

  • In my simplified example since my Power App is shared with Everyone - the external guest user will get access to it without being a member to a group.

Result

  • Switch to an external tenant (special thank you for Blackmores for example here)

  • Fill in the form

  • See the flow trigger and create an invitation from my tenant (Flow Studio Solutions) to guest tenant (Blackmores)

  • The guest email is added as a guest user type in my tenant

  • In the email of the guest email - Microsoft Azure AD sends a B2B invitation email

  • Note the redirect URL is the Power App we will be redirected to at the end of the guest invitation process

  • First time accepting will create this permission dialog reviewing that you (as guest) indeed want to be added to the external tenant. They will see your email, name and photo.

  • After successful redirect - the Power App loads, and look I’m using the Power App as an external user with external email address.

  • If the external user clicks the accept in the email again - they will skip the permission review process and be redirected by Azure AD into the Power App directly.

Variations and extra homework

  • The triggering mechanism doesn’t need to be Microsoft Forms. It can be a HTTP Request trigger that accepts an email address. In a scenario where I’ve build a child tenant to a parent tenant - some javascript on the child tenant send a POST request to the flow to initiate the invitation.

  • The email doesn’t need to be sent directly. The invitation API returns a redemption URL - which can be returned by the Flow in a HTTP Response to a calling javascript, and the user can be redirected to that redemption URL directly without needing to go through an email.

  • You can also capture the redemption URL and create your own email template.

  • You don’t need to redirect to Power App - you can be redirected to a SharePoint extranet that now includes the new guest user. Or to the Teams (by adding the guest user to the team’s group membership).

Using Flow to create Microsoft Teams online events via Microsoft Graph

/

I had a Flow hack a while back to have a Flow button that will instantly create an online teams meeting. Recently, I adapted it into a trigger event that turns my Outlook calendar events (where I’ve forgotten to make it a meeting) into an online meeting.


The techniques needed a bit more exploration, so I did that, and recorded it as a quick 15 minute recording on my YouTube channel. Enjoy!

This is a Flow (Power Automate) that uses Microsoft Graph to create a Teams meeting event invitation. You can use this to invite people inside or outside of ...

Workarounds needed to use the Excel Connector in Microsoft Flow

/

There are two Excel Connectors in Microsoft Flow. There’s a quirk to work with them.

Plan

  • Two Connectors

  • How do we use them? What’s the problem we need this workaround for?

  • Extra tips


Two Connectors

In Microsoft Flow, we now have two connectors for Excel. We have Excel Online (OneDrive) and Excel Online (Business).

There used to be a third Excel connector - which has been deprecated.

How do we use them?

The Excel Connectors call Microsoft Graph under the hood. We need to provide a folder to the file, the file itself, read tables from that file, and then get rows from a table in the Excel file.

To use these connectors, the Excel file must have the data that we want to read in a table.

To use the Excel Online connectors with dynamic file name, we need to find the MSGraph ID of that file. It looks something crazy like:

01BUSAX432CKPX6HWHFJBI7CHAXKHKDHSS

So we build a carefully crafted Send HTTP Request to SharePoint, using the v2.0 endpoint to pull back the MSGraph ID for the selected file.

This then allows us to work with the Excel Online connector.

To use List Rows Present in a Table - we need the Table ID, since this is dynamic now - I’m fetching this with Get Tables (need the file ID).

Then I use an expression to fetch the ID of the first table in the excel 

first(body('Get_tables')?['value'])?['id']

Extra Tips

By default, Excel Online connector retrieves 250 items. We can change the top query param to return 500 or 1000 items.

But to truly get back All the items, we need to switch on Flow’s pagination policy.

See the result - my meteorite.xslx has 49998 rows.

Extra Tips 2

Excel Connector can only retrieve rows via a ‘table’. So if you have to read rows from an Excel file that doesn’t have a table, we can call the Excel Connector action “Create Table” to insert one, then read the rows with that.

This is originally Flow lifehack 96.

https://twitter.com/johnnliu/status/1129715544712597504



Sending email with inline images via MicrosoftGraph and MicrosoftFlow

/

I had previously written how we can use Send Email as Anyone in Microsoft Graph, and as a bonus wrote a section on how we can use it to send inline images.

There was a small problem - sending email is very hard for app-only permissions - app accounts don’t have email boxes. So for that scenario to work, app accounts need a super crazy “send email as anyone” permission.

Sending email is a lot easier with delegate permission - if we have delegate permission Mail.Send - we can send inline attachments very easily. This is not an admin-tenant approval required permission, so any user can grant this.

Plan

Combine two techniques:

To aad.portal.azure.com

Add Mail.Send (delegate permission)

If you can “grant permissions” to your tenant, doing it here will immediately grant this to your current connection.

Otherwise we have to go back to our Flow connectors and make a new connection for batch.

Create our Flow

Here we are creating a MSGraph mail object JSON getting it ready for send

Using a $batch connector - call /me/sendMail

Results

Inline images are super useful for newsletter or emails where you want to include a nice header, signature or whatever in-between. This is a way to send these with Microsoft Graph and Microsoft Flow.

From Office 365 to Azure Event Grid, the events must Flow

/
Photo by Archana More on Unsplash

Photo by Archana More on Unsplash

In this blog post, we capture all the events across an Office 365 Tenant from multiple event sources, gather them, and send them through an Azure Event Grid.

We then listen, filter and handle our events in a central, unified way.

The events must Flow.

This is also the full write up of this microblog posted to Twitter #FlowNinja earlier this month.

Plan

  1. What benefit do we get from this?

  2. Listen to every event across an Office 365 Tenant

  3. Construct a uniform event message

  4. Send them into a Serverless Event Solution - Azure Event Grid

  5. Filter and catch our events

We want to build 3 Flows

flow-event-grid-1.jpg

What benefit do we get from this?

First, we see the increasing availability of event hooks - we have subscriptions, delta queries, or webhooks, across various different products in Office 365. Some products like SharePoint is getting a SocketIO webhook. There will be more events, and our event handling design must evolve.

Second, we see the cost-effective solutions to handle these ever increasing flood of events in the form of Serverless compute. This is true with Azure Functions, Microsoft Flow or Azure Logic Apps.

We end up with a lot of individual event sources and a lot of individual event receivers. This is a common event handling problem. As number of events we handle increases, the worse the event management problem becomes.

Consider you have a “handle a document uploaded to a library” event - a very typical SharePoint Workflow. Now consider this library is cloned to a hundred project sites.

If we clone the event handler a hundred times, we have a problem.

If you have already done this with Flow, then try https://FlowStudio.app to help you manage them.
Ooh inline product placement!

If you are a developer, then consider this scenario.
Consider a typical event handling in the browser. A decade ago we used jQuery like this:

// 2008
$('button').click(handler);

// 2018
$(global).on('click', 'button', handler);

And gradually we find that unacceptable, because we have buttons, events everywhere, and managing individual event hooks was tedious and error prone. Eventually, we moved to a global handler model, and we filter just prior to event being raised.

The headache-less way to handle events is to set the hooks all at the global root level, and then filter by the event source and event type.

That is the exact reason we need Azure Event Grid.

  • Centrally manage our events

  • Decouple the event source from event handlers

  • Stay sane, with a hard problem

Listen to every event across an Office 365 Tenant

I had previously wrote about listening to Office 365 Management API via the HTTP action and app-only permissions. What I did not realize was that the Office 365 Management API also have fantastic webhooks.

I read about the webhooks from Kent Weare’s post, where he uses this event to get a trigger when Flows are created in the tenant.

https://flow.microsoft.com/en-us/blog/automate-flow-governance/

These are grouped into several categories: AzureAD, Exchange, SharePoint and General (other).

This is the subscriber. One picture of 4 blocks. I’m subscribing to three webhooks at once.



The Office 365 Management API is a fantastic general event source. The downside is that it’s not instant - event handler is called between 10-20minutes after the actual event. So it is great as an audit webhook, or for scheduling files or search or to signal for a bot to re-scan a document. But it’s not an instant webhook.

Of course, if our goal is to send events into an Event Grid - we can work with multiple event sources at the same time. We can add Microsoft Graph events or subscribe to SharePoint list webhooks directly.

This is the top of the Listener

Construct a uniform event message

The event grid has a event JSON structure, it also supports a CloudEvent structure.

When I built my implementation, the Event Grid connector is still in preview and I had troubles publishing a Cloud Event structure. I assume this wouldn’t be a problem anymore as the connector evolves.

This is the final loop design - all done.

Remember, we are running Serverless so abuse/utilize every opportunity to use as many Azure Servers as you can - if you can fan-out to parallelism you must.

Don’t talk to each individual HTTP action one at a time. Do (up to 50) all at the same time.


Send them into a Serverless Event solution - Azure Event Grid

The Azure Event Grid is a serverless event processing pipeline. It decouples our event source(s) from our event handlers.

Here is our first handler.

This catches every event on the Event Grid - in Event Grid, we see we have our first webhook attached - it appears as a LogicApps webhook.

Here are three examples of what it caught:

  • Flow created Event

  • Site Collection created Event

  • File uploaded Event

flow-event-grid-3.jpg

Filter and catch our events

We see the very specific webhook now registered on the event grid - and the filters are also listed

PPTX filter only runs when the file I’ve uploaded is a PowerPoint file.


Summary

I have been talking a lot about Serverless and how our tools and design must evolve. Having a unique Office 365 to Event Grid solution is something I talked about as far back as 2017. I’m glad a year later I’ve finally got a great prototype going.

  • Office 365 Management API is a great webhook source that catches all sorts of events. The downside is that it is an audit webhook, so the delay may not be acceptable to your needs.

  • Using Azure Event Grid to perform filtering and subscription gives us the unique ability to see EVERYTHING that’s going on in our tenant. That has tremendous value.

  • Because event source and event handling is now decoupled - we can add new event sources to push to the same Azure Event Grid. We can do this from Microsoft Graph, we can do this from SharePoint, or we can do this from a whole myriad of triggers available in Microsoft Flow

  • We can write Azure Functions to trigger off the Event Grid, and it would be visible as well.

  • I was reading and appreciating sending events to the new Azure SignalR service from Azure Functions - that would be pretty amazing to convert an event grid message into a websocket event.
    https://twitter.com/nthonyChu/status/1044427579460145152

The possibilities are endless. Our tools and our design must evolve.