by It’s pretty impossible to track manually when a file is created in a folder or list of folders. Even if you have a good strategy, you’ll miss files, make mistakes, and, even worse, lose time doing it. That’s why automation exists, and OneDrive for Business “When a file is modified (properties only)” is here to help. It will keep an eye on the folder or a list of folders and trigger with the file’s full metadata when it’s modified. Notice that we’re not getting the file. If you need it, then you should take a look at OneDrive for Business “When a file is modified” trigger, but you do get a lot of metadata that you can work with.
Let’s see how to find it and how to use it.
Where to find it?
You can search for the “When a file is modified (properties only)” trigger or click “OneDrive for Business”.
Select “When a file is modified (properties only)”
Here’s what it looks like.
You can take advantage of some advanced properties that we’ll explore a bit more below.
Power Automate tends to save the most common triggers in the main screen, so check there before going through the full hierarchy. Also, you can use the search to find it quickly.
Let’s see how to use it.
Usage
Using it is pretty simple. You point it to a folder, and it will return the file’s metadata. If you want the file, you need to use the “When a file is modified” trigger. If you know the file identifier, you can include it here, but it’s rare and error-prone to be helpful to do it this way. It’s better to pick the folder from the list of folders in the UI.
As mentioned before, this trigger has advanced options, so let’s explore them now.
Include subfolders
This option is quite handy when detecting files since we are not limited to the folder we select. You can pick this option if you want to see changes to the file in the whole tree of folders underneath the one you chose.
Be aware that files are modified a lot, so enabling this option will trigger this Flow a lot. You need to think about two essential things when allowing this:
- Do I have enough runs to accommodate this? There are limitations to the number of runs, so it’s important not to exhaust them with unnecessary triggers.
- Do I have good filters after the Flow is triggered? It’s uncommon to need all files modified, especially if we’re looking at subfolders, so think if you have enough excellent filters, only files you want to get through the following sections of the Flow.
If you’re looking to solve both issues, one solution can be to limit when the Flow is triggered. You can do it with this strategy, where you create conditions for the Flow to trigger. This way, you can trigger when the file has a type of name, for example, or a specific extension, and you’ll both save Flow runs and filter the data automatically
Number of files to return
This is where things get strange. The trigger doesn’t provide the “Values” action that usually contains an array of elements.
So why include this option? I’m sure that there’s a good reason for this, like bulk parsing the files, but there must be then the “Values” parameter that we can do an ”Apply to each” action.
To be extra sure and careful in case Microsoft changes the behavior in the future, change the option to 1 so that you know that only one file at a time will be returned.
Outputs
The trigger returns metadata from the file, but if you need the entire file, you must use the ““When a file is modified” trigger, which will return the file and some basic metadata. If you need the file after the trigger, you can use the “Get File Content” action with the “File Identifier” you got in the trigger.
Non-intuitive behaviors
It will return only one file, but you have an option to return multiple files at the same time (see above). In my tests, I modified two files within seconds of each other, and the Flow triggered twice as expected.
I don’t know I this is a bug or if Microsoft will change the way it’s implemented, but we need to either have an array as the output of the OneDrive for Business “When a file is modified (properties only)” trigger or don’t have this option.
Limitations
It will only track files that are created. If a file is moved to the folder you’re tracking, it won’t trigger the Flow.
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 a file is modified (properties only)“ 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 in this case since we can get the trigger from anywhere and with anything. Always build the name so that other people can understand what you are using without the need to open the action and check 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 Aziz Acharki on Unsplash
Great Share @Manuel.