The SharePoint connector is one of the complete connectors, especially when it comes to lists. We can do a lot of operations to list items, but the most basic one is to get an item. To help us with that, we have the “Get Item” action.

Let’s explore it a bit further.

Where to find it?

To find it, you can search for “Get Item” action or go to “Standard”:

Then, pick the “Get item” action. Notice that we also have the “Get Items” action, but that fetches a list of items and not only one.

Here’s what it looks like.

Pro Tip:
Power Automate tends to save the most common actions in the main screen, so check there before going trough the full hierarchy. Also you can use the search to quickly find it.

Now that we have the action, let’s check how to use it.


The action is relatively straightforward. It fetches an item from a list. To know what item to bring, we need to provide an ID. The ID is generated and managed by SharePoint. We can’t change it.

You can find it on your list.

If you can’t find it, you can use the “+Add column”, select the last option “show/hide columns” and pick the ID

Here’s how to fetch item 12 in the list above:

And we’ll get something quite complete, so let’s break it down. Here’s the information that you see and define.

But SharePoint stores a LOT more data.

It even provides us with information if it’s a file and the version number of the item.

Some don’t know, but items can be organized in folders. I have a detailed explanation of how to create a list based on folders.

If you don’t have versioning active on your SharePoint lists I would recommend strongly that you do it. I wrote about it here so avoid horror stories and do it sooner than later.

If you want to check the “raw” value, here’s what we get:

  "@odata.etag": "\"2\"",
  "ItemInternalId": "12",
  "ID": 12,
  "Title": "Olivia Cunningham",
  "First_x0020_Name": "Olivia",
  "Last_x0020_Name": "Cunningham",
  "Age": 18,
  "Phone": "711-6754-03",
  "Experience_x0020__x0028_Years_x0": 1,
  "Salary": 6377,
  "Employee": true,
  "Modified": "2021-03-25T18:26:20Z",
  "Created": "2021-03-25T08:56:58Z",
  "Author": {
    "@odata.type": "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
    "Claims": "i:0#.f|membership|",
    "DisplayName": "Manuel Gomes",
    "Email": "",
    "Picture": "",
    "Department": null,
    "JobTitle": null
  "Author#Claims": "i:0#.f|membership|",
  "Editor": {
    "@odata.type": "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
    "Claims": "i:0#.f|membership|",
    "DisplayName": "Manuel Gomes",
    "Email": "",
    "Picture": "",
    "Department": null,
    "JobTitle": null
  "Editor#Claims": "i:0#.f|membership|",
  "{Identifier}": "Lists%252fTest%2bUsers%252f12_.000",
  "{IsFolder}": false,
  "{Thumbnail}": {
    "Large": null,
    "Medium": null,
    "Small": null
  "{Link}": "",
  "{Name}": "Olivia Cunningham",
  "{FilenameWithExtension}": "Olivia Cunningham",
  "{Path}": "Lists/Test Users/",
  "{FullPath}": "Lists/Test Users/12_.000",
  "{HasAttachments}": false,
  "{VersionNumber}": "2.0"

Since Power Automate segments the information for us, we don’t need to parse any information, but it’s handy to understand what happens in the background to fetch the data.

Finally, the ID is a numeric value so be careful when providing this value. Microsoft built some excellent safeguards to avoid this, so you’ll get an error if you try to deliver a string.

Also, if you have a string variable, you won’t be able to use it:

We can get creative, but the point stands. Be careful if you’re providing a valid integer value and if the value exists. Also, be sure that the ID you’re providing is valid. If it’s not, Power Automate will return an error.

Item Not Found
clientRequestId: 0c3a1042-2108-11ec-9621-0242ac130002
serviceRequestId: 115a6270-2108-11ec-9621-0242ac130002

I recommend that you deal with errors and timeouts. Here are my suggestions on how to do it. I also have an article explaining how to do a “try-catch-finally.” Don’t worry; it’s pretty simple, and I provide a template that you can import quickly in your current Flows.

Limit Columns by View

Optionally you can fetch the information based on a view, meaning that the columns defined in the view are the ones that SharePoint will return.

Views can have filter and group the data, but all of that is ignored. The view will only be used to filter the columns.


Although it makes sense to happen, I would prefer that an invalid ID return an empty object and not an error. It would make dealing with errors a lot easier, but I fully agree with the way Microsoft developed this.


Here are some things to keep in mind.

Don’t calculate the ID.

I would strongly advise providing calculated IDs. For example, you may have an object and think, “I want to get the next one,” so it’s the ID+1. By coincidence, it could be, but you can’t be sure, so don’t do it. Also, if Microsoft changes, for some reason, the ID, the rule to generate it, or any other change to the structure, your Flow will return errors, or worse, you’ll be fetching information from incorrect items.

Avoid as much as possible having static IDs.

You should have an excellent reason to have static IDs in the “Get item” action. It’s dangerous to do it since SharePoint controls it. It can generate silent errors and a lot of problems.

For example, think if you have a reference list with data that you access frequently. You can be tempted to fetch the ID = 1 that contains the data you need. However, months past and the reference list was migrated. Another person changes your Flow and migrates the action to the new list but now the ID = 1 is 5 in the new list. If you, for some reason, don’t change the ID, from that point forward, the Flow will fetch invalid data. I know it looks like a fundamental mistake, but these often happen, so not using them protects you from these issues.

Name it correctly

The name is super important in this case since we’re getting the item by either fetching the ID from another action or having a defined static one. 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 to avoid mistakes. Indicate where the ID comes from, for example, if it’s static or not. It’s imperative to mention, if you use a fixed ID, why you’re doing it. There could be a good reason to do it, but it’s unclear if you don’t explain it.

All of this is important to enable faster debugging when something goes wrong.

Always deal with errors.

Have your Flow fail graciously and notify someone that something failed. It’s horrible to have failing Flows in Power Automate since they may go unlooked for a while or generate even worse errors. I have a template, and a template that you can use that will help you make your Flow resistant to issues. You can check all details here.

Am I missing something? Leave a comment or interact on Twitter. Let’s work together to make this reference as complete as we can

Back to the Power Automate Action Reference.

Photo by Oscar Nilsson on Unsplash

Manuel Gomes

I'm a Project Manager with experience in large projects and companies. I've worked in the past for companies like Bayer, Sybase (now SAP) and I'm currently working for Pestana Hotel Group.

View all posts by Manuel Gomes →

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: