Power Automate: SharePoint – When an item is deleted Trigger

SharePoint’s lists are excellent for keeping data, but one accidental delete could generate a lot of headaches, especially if you don’t notice it. That’s why Microsoft developed the “When an item is deleted” trigger, where you can define Flows that do actions when an item is deleted, like a notification to someone to check the “Recycle bin” and see if the item should have been deleted or not.

Let’s check how to take advantage of SharePoint’s “When an item is deleted” trigger.

Where to find it?

To find it, you can search for the “When an item is deleted” trigger or go to “Standard”:

Select “SharePoint”:

Pick the “When an item is deleted” trigger.

Here’s what it looks like.

Usage

It’s pretty easy to configure. You select the site and the list you want to check, and that’s it. For example, if we want to check our “Test Users” list, we’ll do the following:

It will trigger as soon as an item is deleted, but I want to highlight the outputs of this trigger. It won’t return the elements of the item, so you won’t have access to all columns like in the “When an item is created or modified” trigger, for example. You will get the following information:

It makes sense to return this data since the trigger will fire after the item is deleted, so it won’t have access to its information. It will provide information about the deletion, like who deleted it and when.

Non-intuitive behaviors

As mentioned above, not returning all list elements could be considered a non-intuitive behavior. Still, there’s another one I would like to highlight concerning the data returned.

As you can see above, you have the “Is Folder” that is kind of strange on a list, right? We’re dealing with list items, not folders and files, but there’s the indication of “Is Folder”. This is because you can add folders to a list to organize your items. I go into a lot of detail here , so take a look if you want to learn how to use them.

Finally, there’s the possibility to configure SharePoint to keep all changes to the list items. If you don’t know how to do it, check my article on SharePoint’s best practices in the section “Versions”. We can take advantage of this version history and use the “Send an HTTP request to SharePoint “ action to get it. If you don’t know how to do it, here’s an article.

The issue with this is that you won’t be able to do it. You’ll get the following error message:

Item does not exist. It may have been deleted by another user.

Again, the trigger will fire after is deleted, so you won’t have access to its elements unless you manually restore it from the “Recycle Bin”. However, one could consider a “deletion” as a change to the item’s status and worth keeping a version mention of it, but I can understand why Microsoft chose this behavior.

Limitations

The “When an item is deleted” trigger can only be used by site collection admins of the site where the list is located, meaning that if you’re not a site admin, this trigger won’t fire, so keep this in mind in case you’re having issues with the trigger.

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 is deleted“ trigger could be an excellent target to catch items that need deleting. 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 can be used on any list you can access. 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 Gareth Harper on Unsplash