Let’s face it. Large libraries can’t know when a file changes, so automation here is necessary and the only way to do it. With the “When a file is created or modified (properties only)” trigger, you can know when a file changes and get only its properties. Getting the properties may look like a limitation, but it’s a tremendous added value because we may not want the file. We may only need to know that a file was changed so we can take care of it later.
So let’s look at it and how to use it efficiently.
Where to find it?
To find it, you can search for the “When a file is created or modified (properties only)” action.
Pick the “When a file is created or modified (properties only)”
Here’s what it looks like:
Power Automate tends to save the most common triggers on the main screen, so check there before going through the full hierarchy. Also, you can use the search to find it quickly.
There are only three fields that we need to configure, so let’s look at them.
We need a place to search for changes, so we need to configure the site address. There’s no way to know “all sites,” but this is a broad search parameter.
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.
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:
- 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.
- 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
If you expand the “advanced options” you also get the “Limit Columns by View”.
It’s common for SharePoint’s actions to contain this, especially those dealing with lists. You may not think about it that way, but everything in SharePoint is a list, even if you don’t notice it. You have the “vanilla” lists, but the document libraries are also lists that are presented to you differently. Don’t believe me? Go to your “Documents” library in any SharePoint list and notice the list. It has a “+Add a column” doesn’t it? Looks familiar?
So you can add additional columns the same way as in lists. And if you can do this, you can also have a limitation of columns you want to pull from the trigger.
It’s not common to use this field, but I recommend limiting it if you have document libraries with a lot of columns. You won’t notice the Flow being slower, but having fewer data to deal with would be better for you while editing and debugging a Flow.
I consider this a limitation, not being able to search for multiple document libraries at the same time, but as we discussed before, each document library is a “list in disguise,” so Microsoft probably has this feature linked to lists; hence it cannot show you for all lists.
Here are some things to keep in mind.
Don’t use this for synchronization
I see many questions regarding file synchronization, and the “When a file is created or 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 files 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.
Friendly advice, stay away from any synchronization activities and let OneDrive for Business, for example, do their job.
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. Limiting the trigger with some custom rules is essential since these are not prominent in the UI. 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 Tim Mossholder on Unsplash