Write files to SharePoint via Power Automate (Attachments and Document Libraries)

Others have written this up, and I smoothed out the errors I was hitting through Matthew's blog post here.  However, I wanted to draft up a slightly different take just to clarify some gotchas as well as solidify the use-case.

This approach fits w/ a series of other posts I've done on:

• allowing users to interact w/ SharePoint data they don't have rights to
• reading JSON data into Collections using Power Automate
• writing JSON data from Collections using Power Automate

And even with:

• starting your app w/ a splash screen vs. OnStart

All of these build into an ecosystem of very supportable and deployable applications that create a minimum of fuss while also being highly adaptable and portable across scenarios.

App Migration - Automated response to share requests for redirected URLs

If anyone has had their IT team decide to start putting the CoE Tookit in place and start dumping your applications into quarantine, then you might benefit from few patterns/tools for migrating applications in a more friendly manner.

When this started in our organization, one of the first things I did was to figure out the best way to communicate with thousands of users on how to point at a new URL.  At least, until "somebody" bothers to follow the process on how to migrate applications across environments and retain the URL.

NOTE: This pattern also works if you just want to move to a new app and deprecate your old one for any reason at all.

Using the Form Control Creatively: More flexible UI pattern

The first application I wrote for PowerApps utilized the Forms control.  It was...OK.  However, I kept bumping up against it limiting my ability to control the UI in ways that I really found problematic.

The pre-built handling for issues w/ Submissions are nice, but the main reason I was using PowerApps was to have a more flexible user experience.  Since that time I only rarely used Forms except when absolutely required.  

Until now.

Stupid Power Automate Tricks

As I have posted before, Power Automate is just terrible.  This is another of those situations where Microsoft had something "on the shelf" and just threw a new wrapper on it and called it done.  The language used is annoying and derived from Azure Logic Apps, the functionality is inconsistent in how it treats certain kinds of complex objects/arrays (I mean, it is consistent in that it is consistently terrible).  and the overall experience for version control is lacking (there is none).

However, here are a few tricks I keep coming back to time and again that I've pulled from other people's blogs but then time and again forget how to do just because I hate this platform so very much.

The "Best" datasource for PowerApps

I give lots of credit for the folks doing Power Platform videos on YouTube.  I too sometimes grab them as a reference.  However, Shane Young did a video a few days back that was just terrible.  My comment in response to him was a little snarky (which he left up and responded to), but then I went into detail of why his delivery on this was wrong.  That comment was deleted (not by me).

So here is my own version of his terrible take on: the best datasource for PowerApps.

To just jump to the answer, it is SharePoint.

I'm sorry.

NOTE: 2025 John here popping in to say none of my opinions have changed.

Starting Your App: Splash Screen vs. OnStart

Microsoft revamped how they handle the OnStart event for PowerApps last year (2022) and they made some additional tweaks this spring.  This has led some people to messing around w/ an array of methods using OnStart and StartScreen and just causing themselves no end of headaches.  Ultimately, there is one way you should start your application, and that is with a Splash Screen that does all of this in one place.

NOTE: It is now June of 2025.  You know what's still working w/o modification?  Everything I wrote below.  You're welcome.

Writing Collections from PowerApps to SharePoint using JSON & Power Automate

I had done this quickly back in October when I first tried out the ParseJSON() function in PowerApps, but hadn't gotten around to documenting it up.  Then when I went checking to see what everyone else had written up I saw that Shane has done a video on this.  Oddly enough, we both approached this nearly identically.

However, I'm dropping this here for posterity and because I always like to read my own typing vs. listening to anybody else's voice.  ;)

If you have solved grabbing lots of records from "somewhere" (i.e. SharePoint) and returning it to your PowerApp as a bundle of JSON using Power Automate, the reverse is now what you need to solve for.  Fortunately, writing out a lot of updates is similarly easy, but also similarly obtuse per guessing exactly how to get it done.  Here's the Q&D on how to make it happen.

Turning JSON data into Collections in PowerApps

After years of futzing about w/ workarounds and hacks, the new ParseJSON() function in Power Apps has given us a glimpse of how this will work for us going forward.  The ability to push data out to other applications has been possible for awhile now, but our ability to consume JSON back into Power Apps easily has eluded most app builders.

While this function is still in the Experimental branch of PowerApps, there is no doubt that some form of this will go forward.  The benefits are massive and this changes everything about how we deploy large-scale applications.

Not to mention the possible security benefits

Stripping HTML tags from SharePoint data at runtime

If you find yourself in a situation where "somebody" imported a bunch of SharePoint data that included what SharePoint decided had some HTML tags in it, then you might wind up with a multiline text field that has whatever value you care about surrounded with some very unique "<div></div>" tags.  Everything might look fine when you're glancing at your original list, but when you query the field you see something like:

<div class="ExternalClassCA06509747B841D08AA4020D3A431C1E">Some Value</div>

And don't think that SharePoint will be nice and use the same tag within that <div> tag.  It will not.  So if you're going to do any manipulation/comparison on that within your PowerApp (like looking for matching values), you're going to need to get rid of that garbage.

While it is of course always better to try and fix the data, if you're in a situation where you don't control it or cannot do it easily (say when you're dealing w/ hundreds of thousands of rows), then it is time to manipulate this within your app.

Power Automate Service accounts / Let users interact with data they have no rights to

The beautiful part of the Power Platform is truly that it is actually DIFFICULT to decouple who is using the application from what that user has the rights to do within the various systems they connect to.  The big focus of this platform has been to make it easy to let people work w/ data, while also tracking that they are doing so.  However, it is stupid-simple (if not exactly obvious at first glance) to grant a PowerApp user the ability to connect to data they otherwise couldn't.