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

4. PA_Graph_ListItems Flow

As this Flow is almost an exact mirror of the PA_Graph_DriveItems Flow,. Accordingly given that the steps in the PA_Graph_DriveItems Flow of most relevance have equally been comprehensively articulated in the preceding section of this blog, there is no real value in rehashing the same concepts that equally apply to this Flow, bar perhaps a couple of noteworthy exceptions worth calling out.

From a logical perspective this Flow returns a collection of items in any given List in SharePoint being queried. Comparatively speaking the PA_Graph_DriveItems Flow, albeit it somewhat more complex, conceptually surfaces similar type of content inclusive of any metadata fields specific to the columns in the corresponding Document Library folder being queried.

Before elaborating further, let’s look at an overview of all the steps defined in this Flow:

PowerApps Trigger

The Power Apps Trigger action that instantiates this Flow, in addition the subsequent step in this Flow, does nothing more include an If statement to calculate the value of the Uri property for the next step in the Flow.

Get List Items

The purpose of the Get List Items step in the Flow is to determine which input parameters passed to the Flow are of relevance for each Flow run

The Uri constructed in the Get List Items Uri property should by all accounts look similar to the following example Uri string:

If( not ( equals( triggerBody()['odatanextLink_Value'], 'false' ) ), triggerBody()['odatanextLink_Value'], concat('_api/v2.0/sites/',triggerBody()['GetDriveItems_Uri'], '/items?$select=id,parentReference,webUrl,lastModifiedBy,createdBy,createdDateTime,lastModifiedDateTime&$expand=fields', triggerBody()['OdataQueryParameter_Value']))

Put perhaps somewhat more simplyP

The subsequent step in this Flow is a Send an HTTP request to SharePoint step that in turn calls the relevant SharePoint Graph v2 Get Items In a List API for the List being queried in any given Flow run of this Flow. The purpose of Graph v2 List children of a driveItem API, to quote is:

Gets the collection of items in a list.


Seemingly simple, this step in the Flow is anything but simple, depending on how reusable you would like this Flow to be in order that it can consumed for completely disparate use case scenarios that may be a requirement for other apps created in your organization.

The complexity in this step stems from the sample payload you use to generate the schema this action requires.

For example, based on the Test run for the Flow I created, the Schema definition automatically generated based upon the sample payload returned for a simple List that had no custom fields / columns added to that List and as such only a limited number of “required” properties defined in the schema definition.

The response returned in this step of the Flow will contain the collection of all the list items up to the maximum number of rows specified for page size input parameter passed to this Flow from PowerApps.

  • Get Drive Items Uri ( String )
    The value passed into this input parameter of the Flow is ignored if the odata.nextLink input parameter passed to the Flow is anything other than false.
    • The value of this input parameter will be in the following format:

      It is at this point where the relationship between this Flow and the PA_Graph_Site_List_Libraries Flow becomes pertinent.

      The parameter value to pass to the Flow from PowerApps for any given List in a site surfaced in the result set of the PA_Graph_Site_List_Libraries Flow run will be the value of the SiteIdListLibraryId as is defined in Select Return Fields step of said Flow.

      For example, the value of SiteIdListLibraryId should look similar as follows:
    • As this point the noteworthy exceptions alluded to earlier pertaining to the information exposed and surfaced by the Graph v2 List children of a driveItem API for any given Document Library folder queried in the PA_Graph_DriveItems Flow when compared to the equivalent information exposed and surfaced for List items from the SharePoint Graph v2 Get Items In a List API for the List being queried in this Flow become apparent.

      At minimum some noteworthy exceptions include:
      • This Graph API does not expose folders in any given List.
      • The total count of items in any given List is not exposed.
        I do howerver know exactly how to expose both of these limitations of this particular Graph API and will share that insight in a latter blog….
  • Odata Query Parameter ( String )
    The value passed into this input parameter of the Flow is ignored if the odata.nextLink input parameter passed to the Flow is anything other than false.

    Technically you “should” be able to pass in any valid Odata system query parameter(s) for this input parameter of the Flow. However with that said, as best I could assertation only the $top Odata query parameter has, at the time of publishing the blog, been implemented for the SharePoint Graph v2 Get Items In a List API endpoint, whereas with v1 endpoint of the same API other Odata query parameter(s) such as $filter have also been implemented and are supported.

    In the demo app showcased in this blog I only make of the &$top=### page size (aka threshold) Odata query string parameter such that the Flow can then automatically provide to paging functionality as has been demonstrated in the demo app solution showcased.
    • For example, to return the first 250 items within any given List, the value of this parameter would be &$top=250. If so desired you can increase the page size to as high as 5000, and in doing so essentially override the maximum data row limit of 2000 rows you would otherwise natively be constrained / limited to in PowerApps. Just because you can though doesn’t mean you should!
  • odata.nextLink ( String )
    If, having called this Flow previously for any given folder in a Document Library whereby the total number of files and subfolders in that folder exceeds the page size as was specified for the Odata Query Parameter in the previous Flow run, the response for the previous Flow run will include a URL in the odata.nextLink property as is defined in the Select List Items Return Fields of this same Flow.

    This URL in turn references the next page of results and accordingly enables the functionality with your app to handle automated paging, regardless of how many rows (items) the List being queried may contain (i.e. easily 10k+).

    Should you pass any value other than false for this input parameter to the Flow, the other input parameters passed to the Flow will be ignored. With that said the other input parameters are nonetheless required / mandatory input parameters. As was the case with the PA_Graph_DriveItems Flow, equally with this Flow you can pass in any rubbish for the other 2 input parameters as those parameters will in any case be ignored if this input parameter is present (i.e. not false).

Furthermore exactly same logical deductions can just as well be applied to all of the the other steps in this Flow by simply drawing a comparison for each step in this Flow to the effective corresponding step(s) in the PA_Graph_DriveItems Flow.

Up next: 5. PA_Graph_Item_Versions Flow

9 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.

  2. Hi,
    I found this amazing blog post of yours through the Power Apps Community page:
    where you said, “I’ve now also shared a link to download the simplified PowerApp on my related blog post.” I’ve been looking for the link to download the PowerApp but can’t find it. Is this the blog where the link is located?

    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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.