Microsoft Flow: Create a Flow Log in SharePoint to Display Flow Run Outcomes to Your Users


As you're probably aware, Microsoft Flow already provides a list of Flows and their outcomes when you visit your 'My Flows' page.


However, if your Flow is triggered regularly but only really does something occasionally not every run displayed here is relevant. In addition, since each run is labeled only with the outcome, how long ago it was run, and duration, finding a specific Flow run can sometimes feel like a shot in the dark.

In my case, the Flow in question was tied to a very active SharePoint document library and triggered 'When an item is created or modified'.

More specifically, I was looking to move new and updated Excel Macro-enabled workbooks into a fileshare which acted as a pickup location for a separately developed business application. Here's what my Flow looks like:


In essence, the Flow does a conditional check to see if the file is an Excel file. If it is, it copies it. If not, it does nothing. I only care about the Flows that involve the Excel workbooks - but on any given day I could have 15 to 20 non-Excel files for every 1 Excel workbook.

That one Flow run that I actually care about? It quickly gets lost in a sea of those I don't!


Because this Flow is part of a larger business application that is relied upon heavily, I wanted to be proactive in capturing and notifying the business of any issues - and also give them peace of mind when things are working as they should.

With that lengthy introduction out of the way, I can finally go over the solution I came up with to meet my needs (thanks for hanging in there!).


Here's a basic rundown of what we've got going on.

I've created a SharePoint list named 'Import Logs'. This will be used to display only the Flows I care about.


Inside of this list is are columns for:
  • Filename,
  • Link to item,
  • Date of run,
  • Flow outcome,
  • Resolved (to keep track of resolved issues),
  • Folder path and,
  • Flow Run URL.
Nothing too fancy, since I want my end-users to be able to quickly gleam the Flow's activity and health at a glance.

Inside of the Flow itself, we make good use of the 'Configure run after' settings tied to the most vital action we have here - the copy file action.


For the unfamiliar, this setting allows you to dictate what should happen after an action has a specified outcome. It's especially handy because rather than simply having a Flow fail completely because of an error in an action, you can mitigate the impact by doing subsequent actions (for example, wait a few minutes before trying the action again).

Now, back to my 'Copy file' - this action relies on a Data Gateway which, through no fault of its own, can sometimes be unavailable due to network issues.

During testing, it became glaringly obvious that unless I was constantly looking at the dashboard for this Flow, seeing and remediating any errors without some more fleshed out notifications than what Flow provides out of the box would be painful.

To get started, I created a new scope that is set to run in the event that the 'Copy item' action fails or times out.


As you can see above, among the actions included in the scope is the SharePoint 'Create item' action. We'll use this to log the error to our import log. This action inherits the scope's 'Configure run after' as it is the first one inside of it.

After finding our 'Import Log' list, the property mappings are pretty straightforward:
  • Name -> 'File name with extension'
  • Link to item -> 'Link to item'
  • Date/Time -> utcNow() - this one's a function
  • Outcome -> 'Error', since this particular action is running after copy file has an error.
  • Resolved -> 'No'
  • Link to folder -> concat('', Folder path) - folder path in this case comes from your trigger action.
  • Flow Run URL -> Lets discuss...
The last one, Flow Run URL, has proven itself invaluable in quickly resolving any issues. It provides us a direct link to this specific Flow run, where we can see what went wrong and more importantly resubmit the Flow once we're confident the issue is resolved. Sticking the Flow Run URL on this list also helps us avoid the trouble of digging through all the other irrelevant runs through the dashboard!

Unfortunately, as far as I could tell Microsoft doesn't readily give us this information through a dedicated function. It took a bit of trial-and-error to come up with something that spits this out for us to use. The effort was well worth it, though.

I'll explain what it's doing in more detail below, but for those who are simply looking for the function - here you go!
Breaking it down, you can see it is composed of static pieces and functions (the bold portions). The concat() just brings it all together for us.

The workflow() function returns an object with the details of the Flow in general and the Flow instance in particular. To get to the specific parameters we have to drill down into this object.
  • workflow().tags.environmentName - this returns the value of your Flow environment, which is unique to your organization.
  • workflow().name - this returns the encoded name of your Flow.
  • workflow() - finally, this returns the unique identifier for this specific Flow run.
As an aside, you can dig into any action and trigger in your Flow. This can prove very powerful as you develop your Flows since it can give you more building blocks from which to work with.

Now that you know what the function does, throw it into a string variable ('stringFlowRunUrl') by placing it in the expression field and clicking 'Ok' to set the variable to it.



Finally dump this variable into the SharePoint 'Create item' action and you've now successfully logged the error!


The next two actions simply send an email notifying us of the error (with a convenient link to both the Import Log entry we just generated and the Flow Run itself) and then terminates this Flow on our own terms.


The last piece of this puzzle is logging a successful Flow run to assure the business that all is indeed quiet on the western front.

To do so, we'll set up another SharePoint 'Create item' action - but this time we'll configure it to run after the preceeding action is skipped. The assumption is if the error logging action is skipped, then there was no error and as a result we want to create a similar entry with the outcome of 'Success'.


When all is said and done, you have a neatly packaged Flow log that you gives your users much greater insight into the Flows activities. You can share the Flow itself with them as well, which would allow them to access and then resubmit any Flows that failed by clicking on that Flow Run Url.

As a bonus, unlike the Flows run history, this log isn't lost after 30 days - though the links to the Flow run won't work.