PowerApps & SharePoint – The Ultimate User Experience – Dynamic Data Sources – Graph – Power Automate

Beyond Belief: Fact or Fiction is an American television anthology series created by Lynn Lehmann, presented by Dick Clark Productions, and produced and aired by the Fox network from 1997 to 2002. Each episode featured stories, all of which appeared to defy logic, and some of which were allegedly based on actual events. The viewer was offered the challenge of determining which are true and which are false. At the end of the show, it was revealed to the viewer whether the tales were true or works of fiction.

The reasoning for the indifferent title I have given for this blog is honestly because I have spent far too much time trying to find the appropriate few words to articulate and contextualize the scope of what this blog covers.

The word contextualize being a more befitting word to use in order to “illustrate an abstract concept by analogy with” the television series Beyond Belief: Fact or Fiction and follow that type of format throughout this blog.

Introduction

The intent of this blog is to accept the challenge(s) of determining how much functionality can in fact be implemented in an app created using PowerApps as that functionality specifically pertains to consuming content stored in SharePoint Online regardless of which site or subsite, document library including folders as well as customs lists is queried.

This blog, by way of example, should hopefully demonstrate how App Makers can in fact consume content from SharePoint based upon a completely different approach that App Makers by and large use have until now at least have either:

  • Automatically written off this type of approach to consider using within their own apps as the greater citizen developer generally runs for the hills upon hearing the word Flow, as they have come to associate a Flow as being a complexifier insofar as creating their own apps is concerned.
  • Alternatively App Makers who are quite comfortable using Flows within their own apps generally do so for completely different objectives in mind and seldom if ever with the type of objectives that this blog intends to address.

The solution as described in this blog is of course constrained to a number of quite specific use case scenarios that many App Makers I believe will find of particular interest insofar the broader concept and design patterns this blog speaks to.

The same general concepts / design patterns as are detailed in this blog can equally enable countless other use scenarios leveraging other SharePoint and OneDrive Graph v2 APIs, more specifically to various Graph v2 APIs related to Sites and lists in addition to various Graph v2 APIs related to Files.

Power Apps SharePoint User Experience Demo

The demo app I have created and is showcased in the video by all accounts speaks to the type of functionality that is in fact possible today to implement by PowerApps App Makers.

Important

This blog may well be one of the longest blogs you’ll ever come across! It contains a substantially amount of detailed technical information that is unquestionably not for the faint-hearted.

That said, the average citizen developer can by all means skip past all the technicalities articulated for each of the 7 Flows described in this blog by simply scrolling down to the final section in this blog where you’ll find a link to download all 7 of the Flows, subsequent to which you can then import those Flows into your own environment. I have also shared a simplified version of the primary demo app showcased in this blog such that anyone can deploy that PowerApp to their own environment and see how simple it really is to leverage the techniques described in this blog to surface all types of content stored on any SharePoint site!

Have a look at the Logical Architecture of the relationships between each of the Flows.

Thereafter create an app for testing purposes. Add all of the Flows to that app, following which you can test and evaluate what each of the Flows do by reviewing the result sets returned by each of the Flows.

Whenever is unclear to you how to construct the input parameters you may to need pass to any given Flow, simply revisit this blog. Skip to the section in this blog for the corresponding Flow and review the opening few paragraphs in that section. Hopefully that should provide you with sufficient insight insofar as how to construct the input parameters you’ll need to pass to that Flow from your app in order for that Flow to return a meaningful result set to your apps.

In accordance with disclaimer Microsoft state in terms of the usage of the supposed beta versions of the Graph v2 APIs to quote “in production applications is not supported“, I equally as such have to cite that same disclaimer as all the functionality showcased in this blog is entirely made possible leveraging the Graph v2 “beta” APIs.

Important

APIs under the /beta version in Microsoft Graph are subject to change. Use of these APIs in production applications is not supported.

Take that disclaimer as you so choose.

I can assure you that some of the SharePoint Graph v2 APIs do not exactly work as they are supposed to. Having spent an extensive amount of time working with the SharePoint Graph v2 APIs, I encountered several must-have functional requirements for a number of the APIs that evidently as yet have not been implemented, equally for some of the must-have requirement they well by contributing factors in so far as why those v2 APIs are still been deemed to officially still be in beta.

Put in perspective however, in the video where I demonstrate the type of functionality you can in fact implement in your apps using the SharePoint Graph v2 APIs enables you to accomplish capabilities in your apps that are still on the to-do list of features requested to be implemented natively within PowerApps, a number of which for as long as 3+ years. So even if some of the functionality showcased in this blog only covers 50% of what you’d like it to do, that’s still 50% more than you can do now.

This blog and the corresponding demo app is intentionally confined to what App Makers can implement by leveraging nothing more the SharePoint v2 Graph APIs in their current state such that are no misconceptions with regards to any capabilities demonstrated that might somehow be made possible with anything more than the functionality implemented in the 7 Power Automate Flows shared in this blog, aka “David Blaine” style ?.

Fact or Fiction

As opposed to putting in my own words the “challenges” this blog intends to cover, and equally the type of audience I believe may quite possibly be interested in reading this blog, I have abstracted some of the top Ideas App Makers have suggested for future features on the PowerApps Community website that have as yet not been implemented as native functionality in Power Apps. This begs a couple of quick questions to the audience who may be reading this blog at this point time:

  • Can so much content from SharePoint in fact be exposed by leveraging 7 relatively simply Power Automate Flows?
  • Is it really possible to implement all that functionality consuming most types of data stored in SharePoint into a single PowerApp containing no more than a single screen with absolutely zero Connectors associated to the App in any way, aside from the 7 Power Automate Flows?
  • Many App Makers have voiced their frustrations that is not possible in PowerApps to reuse their apps on alternative Sites, Document Libraries or Lists for matter, regardless of whether or not those alternate entities have identical columns to that of the entities around which the original app they created was based upon.
  • Question: If the 7 Flows I proclaim are supposedly relatively so simple, why then is this blog so long?
    Answer: I like to waffle ?.

More Waffle ?

Magic enables people to experience the impossible … many technological advances can be directly traced to the influential work of magicians … futurist Arthur C. Clarke claimed that any sufficiently advanced technology is indistinguishable from magic … magic fulfills some of the highest ideals and aspirations…by encouraging people to question what they believe and see … an art that transforms the ordinary into the extraordinary

U.S. Congress Resolution H. RES. 642
Recognizing magic as a rare and valuable art form and national treasure
In The House of Representatives, March 14, 2016

Any radical new invention certainly feels magical

David Blaine White (born April 4, 1973) is an American illusionist, endurance artist and extreme performer. … “On the April 30, 2008” David Blain broke “the Guinness World Record for oxygen assisted static apnea” having “held his breath for 17 minutes 4-1/2 seconds

No doubt, why the waffle on magic?

The idea of posting a blog such as this one that speaks to a full end-to-end implementation of a single PowerApp that has absolutely no hardcoded connections or links to any SharePoint Lists or Document Libraries for that matter can be categorized in the realm of “Is this perhaps all just smoke and mirrors?”.

When one considers some of the fantastic capabilities showcased in the demo app, at times delving into unchartered territory, compounded with the concept that all the functionality showcased has been implemented into a single Power App, containing just one screen for that matter, whilst stupendously able to furthermore surface a substantial amount of content stored anywhere on your SharePoint tenant is by all accounts legendary, even if I dare say so myself ?.

I couldn’t resist throwing the previous paragraph into this blog because David Blaine is just 26 days older than I am, and he also set a Guinness World Record on my birthday ?. So there must be something mystical about that month many moons ago LOL.

The overwhelming objectives of writing this unquestionably long blog, along with creating what I certainly believe is pretty awesome demo app is that in doing so, is that it transforms what would otherwise be a disparate series of blogs, each perhaps speaking what any given Flow does. However by withholding publishing this blog until each of the elements of the overall solution were adequately articulated in this blog, what I hope I have now been able to accomplish is to speak far further into point-specific functionality that would wise have been posted in multiple series of blogs, thus revolutionizes what type of functionality showcased in the demo app is possible to implement in your own apps today.

This list below includes a number of ideas put forward by the Power Apps Community that, at the time of posting this blog, have yet to implemented as native features and capabilities that App Makers have been asking for quite some time.

These ideas encompass the objectives this blog sets out to solve:

With all that said, the one thing I did find was that it was impossible to implement some capabilities in the demo appp because of functionality that as yet has not yet been implemented in the corrosponding Graph v2 API. The real frustration I encountered with this though was mostly pertaining to the fact the documentation for that API rarely reflects if any functionality that is supposed to be possible using the API has however not yet been implemented. Equally the examples of how to use those APIs are rarely helpful.

  • Support for Folders and Subfolders using the v2.0 Graphs in List and list items within a List.
    Where there is a will there always a way [teaser alert…]
  • For the Graph v2 Update an item in a list API as least one or more field types are not (currently) support yet, such as Taxomomy / managed metadata columns.

Flows Consumed in the Demo App

All the functionality as is showcased in the video demo is driven by 7 Flows, 6 of which include just one Send an HTTP request to SharePoint action step to query the Microsoft Graph v2 APIs for SharePoint / OneDrive. The 7th Flow includes four Send an HTTP request to SharePoint action steps querying the Graph v2.0 APIs, 4 times more complex (or simple) than any of the other Flows (if you like).

The other steps in each of Flows, excluding the PowerApps trigger action to instantiate each of the Flows as well as the 1-2 action steps that specify what specific information from SharePoint to return to the app, are in essence there for the sake of either manipulating some of the data returned from the Graph v2 API step(s) or alternatively decompartmentalizing certain actions for readability ( 23 letter word of the day: decompartmentalizations ? ).

Logical Architecture

These 7 Flows can be depicted in a logical structure that correlates with how each of the Flows is consumed by the demo app as follows:

Whilst developing and implementing the 7 Flows that form part of the solution showcased in this blog, I went great lengths wherever I could such that as far as possible such that each Flow has been structured in a consistent well defined format / pattern.

The relationship between each of the Flows is by all accounts relatively simplistic to follow.

  • 1. PA_Graph_Search_Sites
    This Flow is used to search for sites in SharePoint based on a Search Query String parameter passed to the Flow when the Flow is instantiated from the app.
    • 2. PA_Graph_Site_List_Libraries
      This Flow (the most “complex”) returns a list of Subsites, Document Libraries and Lists for any given site (or subsite for that matter).
      • 3. PA_Graph_DriveItems
        This Flows returns the list of files and subfolders within a Document Library or within a specific Folder in a Document Library.
      • 4. PA_Graph_ListItems
        This Flows returns the list items in any given List.
      • 5. PA_Graph_Item_Versions
        The sole reason for including this Flow within the overall solution was to demonstrate by way of example how easily additional information can be surfaced leveraging the SharePoint Graph v2.0 APIs. In fact it most likely would work equally with Document Libraries, I just didn’t get around to testing that.
      • 6. PA_Graph_Site_List_Library_Columns
        Returns all the metadata (aka Fields / Columns) and definition thereof for any given Document Library or List.
      • 7. PA_Graph_Item_Patch
        Unbelievably simple, this Flow is used to update the metadata properties for any given file stored within a Document Library or alternatively any given item stored within a List. Unfortunately it appears this API is not yet supported as some functionality has not yet been fully implemented, such as updating Managed Metadata field types, Hyperlink or Picture field types and People Picker field fields. There is however another way to do this which I will blog on when I get some time to test it out…

Up next: 1. PA_Graph_Search_Sites Flow

11 thoughts on “PowerApps & SharePoint – The Ultimate User Experience – Dynamic Data Sources – Graph – Power Automate”

  1. Get Drive Items doesn’t seem to be available anymore? I couldn’t figure out an easy way to do this, other than either creating my own connector to graph API or using the HTTP request action.

    1. The link to a GitHub repository “was” at the end of the blog however I made it private because I have been considering modifying some of the flows to “possibly” make them easier to follow and equally surface more information.

      That said I’ve “temporarily” made the GitHub repository for the original flows publically viewable again, albeit that I will make it private again in a few days. Primarily because I am working on a new blog where there is a lot functionality I’ve been developing such that it will be that much easier to read the new blog, follow the technical site and leverage for use in App Makers own apps. The new blow secifically pertains to changes made to the PA_Graph_DriveItems flow in this blog.

      GitHub – Office365Master/PowerApps-SharePoint—The-Ultimate-User-Experience
      https://github.com/Office365Master/PowerApps-SharePoint—The-Ultimate-User-Experience

Comments are closed.