Upload Image from PowerApps to Flow to SharePoint via an Unused Outlook connector

This is the simplest no code approach to the PowerApps image upload problem so far. Far simpler than with Azure Function, with custom connector, with hacked Flow button via Flow Studio, even simpler than Azure Blob Storage. All standard connectors so no premium required, and no risk of PowerApps trigger resetting and breaking the connection.

This is my simplest method to upload any image from PowerApps to SharePoint

  • No Swagger

  • No Edit JSON

  • No Azure Blob Storage

  • All Standard Connectors

  • No HTTP

  • Can easily add more arguments

Original

This blog post is a cleaned up version of the #Flow Ninja hack 87 thread which happened on Sunday night. https://twitter.com/johnnliu/status/1114863521525669888

Follow me on Twitter and catch the next live hack.

Steps - first a bit of study and exploration

I have a @MicrosoftFlow hack this evening to send files from @PowerApps to @SharePoint I have been thinking about this one for a while. So if you are still awake, follow along.

First - I check the Flow button trigger.
Then create a PowerApps trigger, use peek code to study

Double check SharePoint connector - I read this with FlowStudioApp - there's no method that takes format: byte. Everything wants format: binary.

I spent a while looking through various standard connectors looking for something that does format: byte - I found one. In the Outlook connector.
In send email with attachment. **cackle** **evil grin**

Evil twinkle in the eye acquired - we now execute the plan

So we hack the PowerApps trigger. by using a totally unrelated connector.
I can't hold back my dislike of the PowerApps trigger. Why can't it behave more like the Flow button trigger...

The argument sendanemail_attachmentscontent is ugly. Try using Flow Studio to rename them first before you go too far. This will also make the connection tidier when you take it over to PowerApps.

Finally

PowerApps time - this is probably my simplest method.
Don't need Azure blob storage
Don't need edit json
Don't need swagger
Can have multiple arguments

5-2.png

Just need to conditionally build a strange Flow that doesn't use the outlook connector but use it to lock the PowerApps trigger

  • See the condition is always false - it doesn’t run

  • See also the Size of the create file is much larger than a broken blob string

  • We need to keep the unused Send an email action even if we don’t use it - because it locks the PowerApps trigger in place so the trigger doesn’t reset.


And there we have it - the absolutely simplest no-code solution to send a File from PowerApps to SharePoint with ease.

We lock the PowerApps trigger to format: byte by using an otherwise unused Outlook send mail connector.

Future

There are a few things Microsoft could do that will make this even easier. If they ever get around to it:

  • Allow us to define PowerApps trigger directly either by using Flow Button UI or Request schema

  • Allow SharePoint connector to accept format: byte

  • Allow PowerApps to send format: binary, right now PowerApps converts that to string, dropping the non-character bytes from the data it sends to Flow






How to implement Sort with Microsoft Flow in 3 actions within a loop

Photo by Sophie Elvis on Unsplash

Photo by Sophie Elvis on Unsplash

For some reason, Flow (and LogicApps) doesn’t have a built in sort() method.

So after much nudging from Paul Culmsee, I brooded about this and sat down and built one. There’s three actions within a loop, packing quite a lot of tricks, this is how it all works.

Plan

How does it work conceptually?

Build your own Sort in Microsoft Flow

Simplify it to 3 actions within a loop

Extend it to sort objects and beyond.


Defining what we need


Let’s set up some input and outputs - we want to have our initial variable within the variable “initial-array” and we want to have our final sorted result within the variable “sorted-array”

We want to do a simple insertion sort - for the academic - this is an O(n^2) sort. Not the fastest, but simple enough to understand and express with logic expressions.

How does it work conceptually?

For each element in the initial-array, we will loop add it to a final ‘sorted-array’ in a sorted position.

In the first loop, the sorted array would be empty - but as we progress, for each new value we are considering - we would split the sorted-array into two sets of sub-arrays, ones that are smaller than the current value, and ones that are larger than the current value.

Finally, we combine everything back together in a union, set that to be the new “sorted-array” value, and proceed with the next element in the initial-array.

Build your own Sort in Microsoft Flow

So extending our Flow - add a loop over the initial-array.

Within the loop, we want to put the current item into a compose action. (going with the example above, this would be the element ‘4’ )

Add a compose at the end to see the final output of sorted-array.

Cutting sorted-array into lesser half, greater half

We do this in a parallel branch - these two don’t affect each other - add two Filter Array

Left, set the item() of the sorted-array to be <= the current value of the initial-array
Right, set the item() of the sorted-array to be > the current value of the initial-array

Union the arrays together. That is, the left-array, the right array, and in the middle, the current value, but put that inside an array of 1 element with createArray( <current-value> )

Before the apply to each ends, write the union result back into the “sorted-array” that concludes this loop, getting us ready for the next value.

See how it runs:

The result is a sorted-array.

See for example, loop 6, when the value is ‘4’

Clean up and simplify

We can remove some of the blocks to make the sort ‘smaller’

The final result

3 actions within one loop

Sorting complex (JSON) Objects

It is best to build an sort-array like this with numbers to understand how it works, before attempting to tweak it to sort complex object arrays.

Say for example - if we want to sort by the Date of a complex object array (our scenario was an RSS feed) - within the apply to each, we want to isolate the property we want to compare.

Because the current item’s property is used several times - we add the top compose back into the apply to each loop, we can consider the Compose is a kind of temporary variable used to hold the value that we are using to compare with.

We need to compare against the date in the two Filter-Arrays, but we don’t actually use it for the final Union - because we want to union the arrays together, not union the dates together.

And that’s Sort. Complex explanations, but very elegant with 3 actions inside a loop.

Hiding your Microsoft Flow valuables I mean variables out of sight

Photo by  Annie Spratt  on  Unsplash

Today is a quick #FlowNinja post on a strange technique.

Hiding Microsoft Flow valuables I mean variables out of sight

Yes, a very ninja technique.



This is actually an article about how to use tracked properties in the current Flow. But of course that’s the boring side to this. The fun side is how we can attach properties, like having a utility property bag and store properties as we go along!

Start with three compose (I guess we only need two really)

The expression give us the trackedProperties dictionary off the first action

actions('vars')?['trackedProperties']
// vars is the name of the first Compose action

Toggle to the … settings for the first action - that’s where different tracked properties are defined. We can use expressions if prefixed with the “@…” syntax, or define literal strings or numbers or even nested JSON objects.

What could we use Tracked Properties for?

  • Well, hide things that we don’t want to show - like the back of an envelope.

  • Unfortunately, an action can’t reference itself, so we can’t hide secrets that the action itself needs on the back of itself.

  • Tracking time between two actions - calculating the time difference between approvals can be useful.

  • https://flowstudio.app can ‘see’ tracked property values in the detailed Flow Runs - but there are no UI to display this for now. One idea is to use this to surface data within the Flow run that can be observed at the Runs level - like the Trigger URL or List Item ID of the runs, and allowing sorting on them. Powerful ideas but difficult to build an UI for. Let me know if you are keen about how this works below.

Microsoft Flow HTTP Trigger <> Request Trigger, and you probably don't want to use it

Microsoft Flow has a fairly good UI update today, and with this a few “hidden” built-in triggers appeared.

The GeoFence Trigger is not available yet. But the HTTP Trigger is, and I wanted to write this blog post to explain how it works, and more importantly, why you probably don’t want to use this trigger.


HTTP trigger

Create this, the trigger calls the football API, it fetches back data…

The HTTP trigger is not a “new” trigger - it is something that’s in LogicApps for sometime. In essence, it is a polling trigger. So is this a run-once? Does it run many times? The answer is in the definition.


The Definition

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-actions-triggers#http-trigger

The definition specifies

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "<method-type>",
      "uri": "<endpoint-URL>",
      "headers": { "<header-content>" },
      "body": "<body-content>",
      "authentication": { "<authentication-method>" },
      "retryPolicy": { "<retry-behavior>" },
      "queries": "<query-parameters>"
   },
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "operationOptions": "<operation-option>"
}

But the designer for HTTP trigger does not let us specify the recurrence pattern for this trigger. So it ends up on the default, which is polling at 1 per minute.

That’s probably a really aggressive way to use up your Flow runs :-)

Summary

Four recommendations / notes:

  • Use a Schedule Recurrence trigger to specify what time and frequency we want our polling to run, then call HTTP as an action

  • Wait for a UI update that let us set up the recurrence trigger

  • Use FlowStudio to patch the JSON definition like a hacker. In a future FlowStudio update we will warn when these type of high-run Flows are created in the tenant unintentionally.

  • The Request Trigger turns a Flow into a web service. A HTTP trigger does not accept any requests, having both triggers now in Flow makes describing the correct trigger in text and blogs slightly tricker.

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

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.