Reuse Flows connected to SharePoint Lists – Working again

In our previous attempt (Reuse Flows connected to SharePoint Lists), we tried an approach using the Referer property from the header section of the request to discover which list or document library was triggering the Flow. Using this property, we could get the Site URL and the List ID from SharePoint by dissecting the URI.

The following is an example of the URI received:

"Referer": "https://emea.flow.microsoft.com/en-US/widgets/manage/environments/Default-fdc90c70-0811-412c-8551-e5706c9b92da/flow/run?widgetId=160c0087-bdbb-4080-b04f-68df-a7f6470c&sdkVersion=2.0&widgetType=flowsRuntime&utm_medium=widget&utm_source=SPO&environment=Default-fdc90c70-0811-412c-8551-e5706c9b92da&enableOnBehalfOfTokens=true&enableRegionalPortal=true&enableWidgetV2=true&oAuthHandler=oAuth&backgroundColor=white&parameters.sharepoint.site=https:%2F%2Fpowernimbus.sharepoint.com&parameters.sharepoint.list=bcd445a7-66ed-45a4-9d74-d61e47fbcff8&useServerSideProvisioning=true&pathAlias=flowsRuntime&allowOptionalEvents=true"

Some weeks after posting this workaround, a security policy broke the proposed solution. Because of this, sometimes we receive the expected data, but others we just receive: “Referer”: “https://emea.flow.microsoft.com

Making it difficult to discover information about who triggered the Flow.

A new approach

Remember that in the first post we commented about the itemUrl parameter? SharePoint sends these two types of URIs when triggering the Flow:

Example one:

"https://powernimbus.sharepoint.com/Brochures/Forms/AllItems.aspx#id=%2FBrochures%2FBrochure%20%281%29%2Epdf&parent=%2FBrochures"

Example two:

"https://powernimbus.sharepoint.com/_layouts/15/listform.aspx?PageType=4&ListId=%7BF7B36715-D9B6-40EE-AAEB-89EFD927A0A3%7D&Source=https%3A%2F%2Fampicurrents.sharepoint.com%2FLists%2FMarketing%2520Emails%2FAllItems.aspx&RootFolder=%2FLists%2FMarketing%20Emails&ID=1&ContentTypeId=0x0100C58F40594BFF3C41AB8CB70CAFF4ADE4"

This new approach uses these two types of URIs to discover the SharePoint site and list / library. This is the only change from our previous workaround.

Dissecting data

The following is an overview on how to detect the link type in a Cloud flow:

First, we will use one of the best practices for building flows in Power Automate: Scopes. This way we can build a try-catch mechanism when detecting the SharePoint site URL and List.

The Detect Link type scope dissects the link. If everything goes as expected, the execution will continue to the Main scope, but if there is an issue, it will continue to the Error management scope.

Detecting link type

Through a series of actions and formulas, we will get the information we need. When we receive a link containing the _layouts text, we will get the SharePoint site URL and the List ID in GUID format. The other option will get the SharePoint site URL as well, but you will get the List name instead of the ID.

Power Automate’s SharePoint actions can use List names or GUIDs, but if you want to have a more concise solution, you can also send a request to SharePoint to get the List ID in GUID format so we always have the information in the same format.

Get the code

The proposed solution can be downloaded from the PowerAutomate-Samples GitHub repository. The example is called: Teams Notification Handler.

There’s more

Thanks to this wonderful community, there is another approach to tackle this using subscription information from SharePoint. Take a look at this by visiting Tomasz Poszytek’s blog.

For more great content, check out the Resource Centre

About the Author:

Author | Business Apps MVP | MCT | Team Lead @ Intelequia

Reference:

Mendoza, E. (2021). Reuse Flows connected to SharePoint Lists – Working again. Available at: https://powernimbus.com/2021/03/reuse-flows-connected-to-sharepoint-lists-working-again/ [Accessed 16th April 2021].

Share this on...

Rate this Post:

Share: