Power Automate: SharePoint – When an item or a file is modified Trigger

I have to admit that this is a strange trigger because it mixes items and files, and it doesn’t have a “when created” counterpart. It can be helpful depending on your workflow, so today, we’ll explore the “When an item or a file is modified” trigger and how to take advantage of it.

Where to find it?

To find it, search for the “When an item or a file is modified” trigger or go to “Standard”.

Select “SharePoint”.

Pick the “When an item or a file is modified” trigger.

Here’s what it looks like.

There are some advanced options that you can explore. To add them, press here:

Here’s what it looks like with the options expanded:

Let’s look at the fields and how we can configure them.

Fields

There are a few fields to configure so that you can take advantage of them.

Site address

We need a place to search for changes, so we need to configure the site address. There’s no way to select “all sites,” but this is a broad search parameter since a site could already have a lot of activity. If you want more sites, you need to replicate the trigger to consider all the sites you need.

List or Library Name

Within sites, there are multiple libraries, so we need to indicate what library we want. As before, we cannot have an “all libraries” filter, so if you have a lot of libraries, you need to duplicate the trigger for all of them.

It will also display all the lists on the site; as for the document libraries, you cannot have an “all lists” choice.

Folder

This one is optional and should be used wisely. If we want to get changes from all files, by all means, keep it empty, but it’s always good to limit a bit the number of Flows that we trigger. If you can have the trigger look for folders down the line, it will help you:

1. Having fewer exceptions to parse and reducing the number of folders also limits the number of types of files that you need to look at.
2. Fewer triggers, meaning that you keep your Power Automate usage under control. Remember that triggers are not unlimited, so keeping them controlled will go a long way to avoid having limitation issues in the future.

Limit Columns by View

You can limit the columns that you want to be returned by defining a view in SharePoint, and by doing so, you can speed up your Flow because it will only return a smaller subset of data. But remember that it won’t consider any filters you have defined in the view. As the name indicates, it will only look at the columns in the view, not the data, so it will always return changes to files and items that may not be visible in your view.

Usage

Here’s an example of a document library I created, and we want to check changes to those files.

Since we leave the folder field empty, Power Automate will look at all files in the document library.

What is a modification?

But to understand when the trigger will fire, we need to understand what is a “modification”. A “modification” is when you change the data associated with the item’s metadata and not the file itself. Adding more text to a word file is not a change.

When you see a document library, you’ll notice that the folder structure looks much like the item structure, and that’s for a good reason. They are the same, but since they are different types, SharePoint displays them in a way that makes sense to the user.

Here’s an example of the document library in the example above:

We even have the “+ Add column” option as we have on the list item view.

This is because the document library is a view behind the scenes, meaning we can add additional items to a list, so let’s add a new column called “Status” to test.

Now let’s edit the value. When you’re a list item, you will click on the row, but since this is a file, it will open the file itself and not its properties. You need to do the following:

You’ll notice that we’re not touching the file. We’re not editing the file itself. We’re editing the list item, in this case, a file, because it’s a document library. And this is when the trigger will fire because there was a change to the file.

So the “When an item or a file is modified” trigger will fire when you edit the fields in the list regardless of their type (item or file). I know it’s not intuitive since we think modifying a file by editing it, but this is not how this trigger works.

If you select the folder ensure it is in the document library

Finally, be careful when selecting the folder in case you need it. When you choose a document library, the UI won’t filter the folder list to the ones inside that library and will always list for the site. For example:

Be sure to pick folders inside the document library because Power Automate won’t return an error. The Flow won’t fire because it’s impossible for the file to be in two folders simultaneously.

Outputs

The “When an item or a file is modified” trigger outputs depend on the parameters you pick. For example, in the case above, we have a column “Status”, so the trigger will return it:

But if we pick a list, the UI will adapt and provide the columns for that list.

Non-intuitive behaviors

I mentioned above, but the most non-intuitive behavior for the “When an item or a file is modified” trigger is that the files could be modified (for example, adding a new row in an Excel file). Still, the trigger won’t consider it as a “modification”. It will only consider modifications when you change the columns associated with that document library, as it was a “simple” list.

Limitations

You can’t pick “all document libraries”, so you always have to pick a list or a document library from the list. It’s not really a limitation since it’s a good compromise, but if you have multiple document libraries, you need to replicate the Flow for each document library.

Recommendations

Here are some things to keep in mind.

Don’t use this for synchronization

I see many questions regarding synchronization between SharePoint lists, and the “When an item or a file is modified“ trigger is an excellent target to catch items that need replication. But I would strongly advise you not to do it. Synchronization of items is an amazingly complex topic in computer science, and we are all super when something doesn’t synchronize properly. If the trigger fails, data will be out of sync, and Power Automate won’t rerun it. If the data is changed on the destination list, you already have a problem that will only worsen over time.

Name it correctly

The name is super important since the trigger has a lot of configurations. We should name it, so it’s clear what information we’re getting and why. Always build the name so that other people can understand what you are using without opening the action and checking the details.

Always add a comment

Adding a comment will also help avoid mistakes. Indicate what you’re expecting, why the Flow should be triggered, and what the data will be used. It’s essential to add comments when limiting the trigger with some custom rulessince these are not prominent in the UI, and people may get confused as to why the Flow doesn’t trigger when it’s simply a rule preventing it from doing so. It’s essential to enable faster debugging when something goes wrong.

Finally, let people know why you’re choosing the parameters you configured. For example, why do you select that folder if you have a folder defined? It may make sense now, but not in a few months.

An automated trigger is better than a scheduled one.

Sometimes people are tempted to use scheduled triggers that pool the resources once in a while. This way, they can control when the information is fetched and save much Power Automate “triggers” if their quota is low. However, even if it isn’t, it may be more efficient to do batch tasks than once by one. I understand, and in some cases, I can agree, but it brings a lot of difficulties in the process. For example, you may need to keep track of what changed from the last run until this one so that some things may get lost. Also, you’re forcing something to happen periodically, even if there’s no data.

I always recommend using these “automatic” triggers instead, where they trigger one by one, but only when there’s data, so you’re always sure you get something to do. Also, debugging triggers that parse a single data point instead of multiple simultaneously is much easier. If something fails on one, then you can fix the Flow and repeat the process. But while parsing multiple ones, things can get a lot harder.

Back to the Power Automate Trigger Reference.

Photo by Christopher Bill on Unsplash