Native SharePoint HTTP (Rest) Action for PowerApps

Right now, the SharePoint connection works great for simple use cases, but there are many more complicated use cases arent really working great with out of the box.

A really useful feature/maybe connector would be a SharePoint HTTP action (similar to Flow) that can use the credentials of the current user to make the HTTP Rest call to SharePoint in the context of the current user. This would ensure:

You only get the items that the user has access to

You can get around list lookup limitations of SharePoint

You can get around the delegation and large list filtering

I'd imagine your source on a form or gallery might be something like this:

Something to add here. I'm using Onedrive at the moment for the thumbnail option but, it would be possible to use the much more powerful Sharepoint REST API to retrieve small sized images for the original big image.

You should check out my latest "AMAZING" demo app I have developed for a corrosponding blog I will most likely post within the next week.

For this demo app I do still use the SharePoint HTTP action in 5 Flows I have implemented to enable all the almost unbelievable functionality you'll see in a demo video I have posted on YouTube yesterday. Believe me it's worth watching .

Whilst the request for this idea is to provide some kind of equivalent Connector you can create for your apps whereby App Makers could then tailor the content with the sharepoint odata in the URL, there is absolutely no reason you cannot effectively accomplish the same thing by passing that odata query string as a parameter to a Flow.

Perhaps the most significant obstacle to overcome is that PowerApps requires a well defined schema definition in the Response action that return the data from SharePoint to PowerApps. The same however is required for any Connector for that matter. I figured out a workaround to this though for this latest demo app I've created which I'll explain in more detail in my latest blog.

Without associated a single Connector to the demo app, I've essentially create a complete SharePoint UI within my app that consists of one screen. That's all. In that one screen users can view all the content they have permission to access stored on any site in SharePoint, view all the Document Libraries, Lists and Subsites for the site they've connected to, view PDFs, Word and PowerPoint documents, and potentially other types of documents within their apps, view the metadata for column columns they may have created on Lists, view highly compressed photos stored in the Site Assets or other Document Libraries for that matter as well as videos they may have uploaded into Document Libraries. All of that on one screen in one app.

The type of functionality showcased in the demo app I created address countless feature requests many App Makers have been frustrated for years about, and yet in the demo I have only touched the surface insofar as what IS possible to implement within PowersApps for quite some time in fact,

I should got back to you some time ago about the code written published on that blog, on why in some scenarios it may not have work at worked.

It is is worth mentioning the background behind that, being that no one had even done vaguely close to enabling that kind of fundamentally in a PowerApp, let alone do in such a way that the people photos rendered in the app are so highly compromised even at ultra-high resolutions.

But with said, because the blog spoke to APIs that no one had even considered might be use in created using PowerApps, there were bound to be scenarios I could never have testified, or know what complications there could possibly.

Nonetheless I think I did a pretty good because I didn’t get much feedback saying otherwise 🤗.

Having worked with that specific API since then, is a that in order to use sample code from copying the outputs or the REST API returned in on the test runs you need to do in order to generate a sample payload to use for the subsequent PARSE JSON action, there have be files (and probably photo) in the Document Library you are so the Test Flows against because if you don’t, the sample payload won’t include certain fields that are required to create the proper scheme definition for the PARSE JSON action. If that happens, the Flow app will never work.

In developing that Flow for the blog, I was using the “Site Assets” library on the site perhaps purely by change, and because I used that specific all the steps in the blog worked as I had expected, and were detailed as such in the blog.

I now have a better better understanding such that it now makes sense to me why it would work for me using the Site Assets, whilst others may well have had some issue in they implemented that flow using a empty Document Library to perform the necessary test runs and generate sample payloads for whatever scheme definition they needed to.

The fundamental problem with using a empty Document Library to use for the test runs to help sample data to generate any given scheme definition is that many fields that expose the surface the content the Flow should return will not have defined in the schema definition when the Flow was created, and 9 time out of 10 that’s why people may have experienced issues getting it working such as yourself.

On the plus side, my blogging continues 🤗, and this latest demo video of mine speaks to whole new generation that haven’t been born yet LOL