Get previous versions of SharePoint list items in Power Automate | Quisitive
Get previous versions of SharePoint list items in Power Automate
October 15, 2019
Quisitive
This tutorial video is very useful in explaining how to view & track modified SharePoint list changes, with more in-depth steps below.

There’s no action in Power Automate to access version history of SharePoint list items (or documents for that matter), yet… So how can we get to older versions of a list item in Power Automate including all their old column values? A customer asked today if there’s a way to have a Flow to detect if a certain column has changed (on item change) and then do…stuff.

Luckily, we have all that we need to accomplish this with the help of our best friend: Send an HTTP request to SharePoint.

This tutorial video is very useful in explaining how to view & track modified SharePoint list changes, with more in-depth steps below.

Here are the main steps to access the version history of the SharePoint list:

  1. Trigger on item created/modified, add trigger condition so it doesn’t trigger on create (since that triggers unnecessary runs)
  2. Calculate Previous Version Number, so that we know what version to look for
  3. Get all the SharePoint list item versions from SharePoint using the HTTP request
  4. Parse the result (JSON) from SharePoint
  5. Loop all versions and pull out the version we want (Previous Version)
  6. Do…stuff.

Step 1: Configure trigger with condition

First off, go to the Settings of the trigger step:

And then add the following condition to make sure the Power Automate only runs when the Version is NOT 1.0:

not(contains(triggerBody()?[‘{VersionNumber}’],’1.0′))

Step 2: Calculate previous number

Next step is to calculate the previous number using a Compose action. We can do that by using the sub expression, with a nested int function to convert the version number to an integer (so that ‘sub’ gets two integers to work with). And then we just add “.0” after the expression to get it in the correct format (“2.0”, and not just “2”)

sub(int(triggerBody()?[‘{VersionNumber}’]),1)

Step 3: Call SharePoint and get the version history of SharePoint list

To get the version of our list item we make the HTTP call and pass the ID of the list item. Note that the title of the list is the Display Name, and not the System Name/URL. So even if you were a good developer and you gave the list the system name “catvisitorslog” to get a nice and clean URL, the HTTP call wants “cat visitors log”.

Step 4: Parse the JSON result

This one is a little trickier if you haven’t worked with JSON before. Before adding the action itself. Save the Flow and run it to test that the HTTP call to Get Versions work. Then copy the whole block of JSON from the Body section under outputs:

Then go back to edit the flow and add the Parse JSON action. Add the output body from the Get Versions HTTP call as content, then click “Use sample payload…” to paste in the JSON code you just copied. This will let the Flow know what the data structure looks like and how to parse it out.

Step 5: Loop all versions and do…stuff

Our last step is to loop through the versions we just parsed out, and detect what version we want to pull, and then do something. For this example I am saving the value of the column “Office Location” to see where something moved away from.

Start by creating an Apply for each and give it the results from the “Parse VersionHistory from JSON” since that contains all our versions. Then add a condition that takes the VersionLabel from the looped item (under “Parse VersionHistory from JSON”, and compare that with the output from the “Calculate PreviousVersionNumber” step you created earlier. What this will do is to check each loop if the version number of the loop is in fact the previous version that we want to target. For example if there is 4 versions of the item, it will loop through version 1.0, 2.0 and validate to false, but when it gets to 3.0 it will validate to true and we can start working our magic!

In this example I am just grabbing the value for Office Location and saving that for further logic. So running it will get the location value:

That is it! With this base you can continue building logic to compare what has changed, and trigger actions based on it. Thanks for reading!