In our previous attempt, 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:
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:
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:
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.
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.
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.