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.


[Updated: 2019-04-27] Video version, PnP SharePoint Community Call from Chaks

From @chakkradeep

This community call demo is taken from the SharePoint General Development Special Interest Group recording on 18th of April 2019. In this video Chaks (Microsoft) shows how you can upload files to SharePoint from PowerApps using Microsoft Flow Presenter - Chakkaradeep (Chaks) Chinnakonda Chandran (Microsoft) - @chakkaradeep Full details on the community call from https://developer.microsoft.com/en-us/sharepoint/blogs/sharepoint-dev-community-pnp-general-sp-dev-sig-recording-18th-of-april-2019/ More details on the SharePoint dev community calls from http://aka.ms/sppnp.


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






One Flow to handle them all - how to subscribe to multiple SharePoint lists with one Flow

/

One Flow to handle them all - how to subscribe to multiple SharePoint lists with one Flow

At some point - we think hmm how do we save a Flow as a template and deploy it with all our SharePoint site collections…

and did we just create a massive problem down the road where we have all these duplicate Flows…

and how do we manage versioning and changes to them hmm lets have a think and talk about this.

So instead of all that copying. Let’s try a different idea - what if we have One Flow that Rules them all. It handles events from All the Sites and Libraries, all within one Flow.

Depending on what our Flow actually do - this might be a better approach.

Live Tweet

This is a long overdue write up of an idea of two Flow done as a hack over twitter.  https://twitter.com/johnnliu/status/1002747531506245632

Multi-Part Series: Deploy My Flow

This is a multi-part series called Deploy My Flow. I want to publish discussing the various ways to deploy Flows across SharePoint and Office 365, between dev, test and production environments. Across lists, sites, and tenants.

  • Export and Import

  • Automate - PowerShell, Flow Management and Flow Studio

  • Power Platform Solutions

  • Subscribe to multiple SharePoint Lists with One Flow

Part I - SharePoint Webhooks

A Flow can only listen/trigger from one list, so while in SharePoint as we provision sites - we consider having a way to provision templated Flows to handle each list. 

But let's turn the question around.  Can we have just one Flow to handle multiple lists?
Is it possible to have Flow connect directly to SharePoint's Webhooks and manage events directly with Flow?

 

Why this approach?

  • The Flow triggers listen to and raises events for each individual list or document library. So, out of the box, we can't create one Flow that listens to every list or library.

  • Cloning Flows multiple times has its own challenges:

    • 250 Flow limit (This limit is now 500, you can request a service ticket to raise this number) per account.

    • How do we manage multiple Flows, do we have one master? Does it get exported and imported over existing Flows when we upgrade? What happens with the connections?

    • Can we do these automatically?

  • There’s a lot to discuss, but for this blog post we will focus on a simple pattern

  1. Create a Handler Flow that handles list change events.

  2. Create a second Scheduler Flow that subscribes webhooks from multiple SharePoint lists onto the first Flow.

Reference

We don't start from scratch, we have the excellent materials on docs.microsoft.com from the SharePoint PnP team describing how to attach to SharePoint webhooks via code.

https://docs.microsoft.com/en-us/sharepoint/dev/apis/webhooks/overview-sharepoint-webhooks

We only need to translate this to Flow.

First Create the Scheduler Flow

First - here I’m reading all the lists from SharePoint that’s a document library. Then read the subscriptions on each document library. This end point shows me SharePoint’s webhooks.

TIP: Because I use odata=nometadata a LOT - I end up putting that header into a header_nometa JSON variable and insert it in every Send HTTP Request action.


Create Subscription and handle Resubscription

Next, we check if the webhooks contains has a clientState with the current Flow’s name (Flow names are unique guids).

If not, we create one. The check and filter for ClientState makes sure we don’t subscribe the same event handler to the same document library multiple times. It also makes this “scheduler” flow re-run safe. We can pretty much change the trigger to a recurrence trigger that runs as often as you’d like - say daily.

workflow()?['name']

The Handler

We need a new Flow to handle the document updating. This is the One Flow that does all the work.

Save the Handler Flow and take the HTTP Reques URL back to our Subscriber Flow

And this is the final result - when we run the Subscriber Flow - it iterates through all my document libraries and connects them all to the handler Flow.

Now when documents are updated in these 12 document libraries, my “Handler Flow” will be triggered by SharePoint.

SharePoint webhook subscriptions are valid for 180 days. So at some point our Scheduler Flow will re-run on recurrence and re-subscribe the document libraries. (We can also handle the True condition in the Scheduler Flow to renew webhooks).

Part 2 - Get Changes

We need to go deeper into Get Changes. Your webhook fired, now you need to figure out what changed.

Follow Part 2 here

http://johnliu.net/blog/2019/5/one-flow-to-handle-them-all-part-2-figuring-out-the-changes

@ISSPDEV couldn’t wait for the next part he went ahead with this. And because he wrote in so much detail - I will also link to his work for Part 2.

Apologies

This was a live hack in 06/2018 - I actually have three draft versions of this blog post never finished so never previously published. So moving that forward with this first post. 9 months late is still better than never.

On using Microsoft Flow as a pre-ETL step for Power BI

/
Photo by WeRoad on Unsplash

Photo by WeRoad on Unsplash

A topic I’ve presented a few times to an Power BI crew is the concept that Microsoft Flow makes a great pre-ETL step for Power BI.

I talked to many attendees at Difinity Power BI Conference Auckland about this. It’s probably a time to write this up to summarize my thoughts.

There’s just something nice about having a product called Flow gathering data into your lakes.

Power BI

Power BI - Power Query and DAX is extremely good at crunching numbers.

Flow has variables, branching and loop logic, but they are slow for number crunching. Loop limitations like 5k rows or total number of action steps are also very limiting.

Don’t use Flow to crunch numbers.

Flow

Power BI connects to about 70 sources - Flow connects to about 250 connections.

Flow’s HTTP action and Custom Connector framework is better at gathering data. Automatic paging, more authentication options, retry policy, async HTTP request.

Flow can gather data on Trigger, copy them all to a simple location (e.g. SharePoint library or Azure Blog Storage) for Power BI to start refresh. So data processing can be done in a secure way.

Flow can call Power BI API to start a refresh. Turning the ETL into a trigger-push system. We get the best of both worlds - Flow to gather data, and Power BI to crunch them.

Power BI Scheduled Refresh with Flow

  1. Schedule Refresh requires Flow to call Power BI API with a HTTP Request. But until very recently – this requires a delegate permission (so Flow has to call Power BI as a user) to perform delegate permission call requires a Custom Connector – which is what this blog post from Konstantinos goes into detail about creating.

    https://medium.com/@Konstantinos_Ioannou/refresh-powerbi-dataset-with-microsoft-flow-73836c727c33

  2. In February, Power BI has started releasing application permission to call Power BI API – this work is still in preview and requires quite a lot of set up, it also requires the administrator to approve the permission. App-only read/write everything is a pretty high level permission, non-admin can't grant this.

    https://powerbi.microsoft.com/en-us/blog/use-power-bi-api-with-service-principal-preview/

    pros: easier to call with Service Identity, and HTTP request
    cons: may be impossible to get your admin to approve a new AAD APP permission

  3. The April roadmap says Refresh is an action coming to Flow’s Power BI Connector – this will use delegate permissions and would be much simpler to use. So my thinking is that wait for this to drop after April

    https://docs.microsoft.com/en-us/business-applications-release-notes/April19/microsoft-flow/improved-power-bi-connector

#FlowNinja hack 78 - modifying Modified By and Modified time with Microsoft Flow

/
rodion-kutsaev-59544-unsplash.jpg

In this quick blog post - we talk about how we can tweak the “Modified By” user field and “Modified” datetime field in SharePoint list and document libraries using Microsoft Flow.

This technique follows the very detailed article by MVP Andrew Koltyakov on LinkedIn - he describes how to call it with C#, JSOM and REST. He also has detailed examples of every possible field and what format you’ll need to run this with.

I’m calling it with Flow. So to see the full explanation you’ll have to read Andrew’s article ;-)

Also, before you read any further - please repeat the title of the blog post loudly, really fast 3 times.

Plan

  • Requirements - why do we want this?

  • Call ValidateUpdateListItem method with Flow


Requirements - why do we want this?

  • You have updated a list item - you don’t really want the items to all say “Updated by System Account”.

  • You’ve copied a bunch of files but you don’t want it to all say “Modified (now)”.

  • You want to modify the item but you don’t want to create a new version.

  • You uploaded a file but you don’t want to have two versions when you tweak the metadata.

  • You wanted the update to tell you if the validation fails some SharePoint list item rule (this method will return a validation array object)

I need this. You also need this.

I don’t think we need to explain why you really really need this.


Flow

Here we have an item - modified a few seconds ago by me.

We want to update two values - the Modified By and the Modified (date time) fields.

Note the User is a JSON object that needs to be serialized by string() inside another JSON object.

The modified date is a date value, formatted to the “g” format. This format is usually MM/dd/yyyy HH:MM AA in EN locales. It is DIFFERENT if your environment has different locales. You can use “g” as date time string format to get the correct one for your locale.

Updates: 2020-06

Instead of “g”, we can also use 'yyyy-MM-dd hh:mm:ss' which seems to work for all locales. More reading on this issue.

Also, Mikael pointed out we should use bNewDocumentUpdate: true to avoid creating a new version.

Here is when it runs. Notice the Editor field is escaped JSON string.

Result

The modified date is now Feb 18, 2018!

And the user is someone else - my minion Gandalf.

Extra Date Time Note

Here is an example of using addDays(utcNow(), -365, ‘g’)
So this date is a year before right now, with the ‘g’ date formatting string.

https___pbs.twimg.com_media_Dzr4RL3U8AAAEa2.png

Difinity Conference 2019 Auckland - Hackathon Workshop, Flow and PowerApps

/

I’ll be presenting at Difinity Conference 2019 Auckland on several presentations.

Difinity is the largest Microsoft Data Platform conference in New Zealand. I’ll be presenting two talks - one on Microsoft Flow and one on PowerApps.

dfinity-conf.jpg

Pre-Conf Hackathon/Workshop: Master your inner Flow and PowerApps

This is a whole day workshop covering PowerApps and Microsoft Flow at a beginner to intermediate level, for the Difinity conference - the exercises are tuned for PowerBI integration.

http://difinity.co.nz/pre-conference-workshops-difinity-2019/#CustomConnector

Introduction to PowerApps and Power BI

This session is about two things – it is firstly a thorough introduction about PowerApps, where it came from and where is it going.

And it is also about how the sum is more than the individual parts – when we combine PowerApps and Power BI we can build some truly amazing more interactive reports & dashboards.

How to make everything with Microsoft Flow (advanced)

This is a intermediate-advance level Microsoft Flow session that looks at the very different types of Flow automations that we can do. Whether it is personal automation, enterprise workflows, or developer webservices. Flow is that flexible tool.

Chat!

Those that have met me will know I’m a very chatty person!

I’ll be hanging out at the community booths, so come find me, or tweet me and ask your Flow, PowerApps (or SharePoint) questions!