Power Automate: SharePoint – When a file is deleted Trigger

We delete files manually or manually, so it’s hard to keep track of “when” and “by whom”. Power Automate helps with the “When a file is deleted” trigger that fires each time a file is deleted in a SharePoint site document library. 
I’ll stress this further in the article, but this trigger is not a recovery tool since Power Automate won’t return the file. It fires after the file’s deletion, not before, so you cannot use it for things like automatic file recovery. You can use it as a simple notification system to react when things happen.

Let’s see how to use it.

Where to find it?

You can search for the “When a file is deleted” action or pick SharePoint in the list.

Select “When a file is deleted” trigger

Here’s what it looks like:

Usage

There are only three fields that we need to configure, so let’s look at them.

Site address

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.

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.

Folder

This one is optional, and you should use it 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.

Outputs

The “When a file is deleted” trigger will only return a few pieces of information from the file. Information like the name, who deleted it, and when, but not much more.

This action is meant as an audit and a “notification” more than a recovery system since you cannot access the file (it was already deleted), so any recovery attempt needs to be done by you manually. But it’s nice to know when something happens in case you want to register it in a list, for example, for future reference.

Non-intuitive behaviors

It’s important to understand that this trigger won’t return the deleted file and its characteristics. It will return only a subset of information mentioned in the previous section. It’s non-intuitive since other actions like the “When a file is created or modified (properties only) Trigger” for example, return all file information since it still exists and can be accessible. SharePoint can’t return the information since the file was deleted. Think of it as a last warning after the file is deleted, not before.

Limitations

I consider this a limitation, not being able to search for multiple document libraries at the same time. 

Recommendations

Here are some things to keep in mind.

This is not a recovery system.

Don’t think of the “When a file is deleted” trigger as a recovery mechanism. It will fire after the file’s deletion, so you should use it for notification actions, for example, not recover the file. Remember that files can be deleted automatically using other actions like SharePoint’s “Delete file” action, for example, so if it’s essential to know when something happens, this trigger can help you do that.

SharePoint and Microsoft 365 have audit features.

You can do simple auditing of files, like saving the information that the “When a file is deleted” trigger provides you into a list, but remember that Microsoft has a massive platform for auditing. If you need further auditing abilities, you need to talk with your administrator since most require a higher level of permissions but know that information is available to you.

Don’t use this for synchronization.

I see many questions regarding synchronization between SharePoint lists, and the “When an item is created or 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. 

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 the data you expect and how you use it. 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.

I see people using scheduled triggers to pool the resources and bulk parse data instead of one by one. This way, they control information fetching and save many 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 must keep track of the changes from the last run. Otherwise, you’ll lose data. 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 Markus Winkler on Unsplash