Power Automate: SharePoint – For a selected item Trigger

Did you know you can trigger Power Automate for items directly in SharePoint? Let’s say you have a list of employees and want to trigger a promotion process. You need to notify HR to change their conditions, notify IT that they have new permissions, and probably more. Having a button where you can trigger this directly in SharePoint makes it super easy, and the “For a selected item” trigger helps us catch those requests.

Let’s see how to use it efficiently.

Where to find it?

To find it, you can search for the “For a selected item” trigger or:

Notice that SharePoint shows up in the primary suggestions, but if you don’t see it, you can go to “Standard”:

Select the “For a selected item” trigger.

Here’s what it looks like.

Usage

There’s not a lot that we need to do to configure it. We only need to say where to look for.

Notice that I called it “Employee Promotion.”

Since I defined the list “Test Users” as the target, let’s look at it and where to find it.

SharePoint did all the work in the backend, and it’s already displaying the Flow for us to run. No configuration is needed on the SharePoint side.

When you run, if it’s the first time, you may need to configure/confirm the connections.

After this, the Flow will trigger on Power Automate.

Outputs

The trigger returns a lot of information in a JSON format, although the conversion from JSON is done automatically for you. Here’s an example:

{
    "headers": {
        ...
    },
    "body": {
        "entity": {
            "ID": 1,
            "itemUrl": "https://manueltgomescom.sharepoint.com/sites/Test/_layouts/15/listform.aspx?PageType=4&ListId=%76070d21-7cb8-4daf-83cd-dcfb86ba632d%7D&Source=https%3A%2F%2Fmanueltgomescom.sharepoint.com%2Fsites%2FTest%2FLists%2FTest%2520Users%2FAllItems.aspx&RootFolder=%2Fsites%2FTest%2FLists%2FTest%20Users&ID=1&ContentTypeId=0x01002DEAA719D34B994D3A86F340C65F7E08",
            "fileName": "Sabrina Myers",
            "FileId": "1"
        }
    }
}

Notice that we only got the information about the item, not the item itself. If you’re used to using the “When an item is created” trigger that returns all the information about the “item,” you’ll notice that the “For a selected item” trigger only returns the identification of the item and not much more. To get all the item’s details, you need to use SharePoint’s “Get item” action.

Non-intuitive behaviors

I described it above, but to reiterate, the “For a selected item” trigger won’t return the item’s information.

It will, however, return the ıtem’s identifier so you can get the information and parse it.

Limitations

If you build the Flows in the “My Flows” section, only you will see them in SharePoint. This is not a limitation per se, but it’s something that you should be aware of. If you want other users to see the Flow, you need to share it with them like this:

Add the names or emails.

The Flow will now show in their SharePoint list.

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 “For a selected item” trigger is an excellent target for synchronization of selected items. But I would strongly advise you not to do it. Synchronization of things 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 re-run 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.

The name of the Flow is significant here

Since you’ll be seeing the flow’s name in SharePoint, and it’s your only clue as to what it will do to the selected item, it’s essential o keep the names as straightforward as possible.

In this example, “Request sign-off” is not clear enough. Request sign-off of what? What will happen?

Finally, this is the only exception I see to not use environment clues like “PROD” in the name, for example. Space in SharePoint is limited; if the name is too long, it may be truncated.

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 enable faster debugging when something goes wrong.

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 Mitchel Lensink on Unsplash