I’ve already covered the “When an item is created or modified” trigger, but today, I wanted to cover its small brother, the “When an item is created” trigger. They work the same way, triggering when there’s new information in your SharePoint list, but the main difference is that this one will only fire when an item is created.

Why are there two when the “When an item is created or modified” trigger can do both? To me there are two reasons:

  1. You can trigger only there are new data saving runs in the process. There are limits to how many Flows you can run, so it’s good to keep them, especially if the list is upgraded frequently.
  2. It’s nicer to use. When you use the “When an item is created or modified” trigger, you have to check if the item was created or updated and then branch your Flow to deal with each case. You don’t need to worry about using the “When an item is created” trigger, since you always know that the item was created.

Let’s look at where to find it and how it works.

Where to find it?

To find it, you can search for SharePoint “When an item is created” trigger or go to “SharePoint”:

Then select the trigger:

Here’s what it looks like:

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

Let’s look at how to use it.

Usage

The setup is quite simple. You pick your site and list, and Power Automate does all the work for you.

Optionally you can also pick a view that will limit the columns that will be returned. For lists with a lot of rows and columns, limiting makes things a lot faster and easier to manage on your Flow.

Please note that the view will only filter the columns and not the rows. If you have filters in the view they will be ignored

When a new item is created in Sharepoint, you’ll get the data that was inserted.

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": {
        "Transfer-Encoding": "chunked",
        "Retry-After": "21600",
        "Vary": "Origin,Accept-Encoding",
        "X-SharePointHealthScore": "1",
        "X-MS-SPConnector": "1",
        "X-SP-SERVERSTATE": "ReadOnly=0",
        "DATASERVICEVERSION": "3.0",
        "SPClientServiceRequestDuration": "175",
        "SPRequestGuid": "ef806fa7-6a4c-4434-883e-ff5466a91761",
        "request-id": "0c60ef00-24f5-11ec-9621-0242ac130002",
        "MS-CV": "<redacted>",
        "Strict-Transport-Security": "max-age=31536000",
        "X-FRAME-OPTIONS": "SAMEORIGIN",
        "Content-Security-Policy": "frame-ancestors 'self' teams.microsoft.com *.teams.microsoft.com *.skype.com *.teams.microsoft.us local.teams.office.com *.powerapps.com *.yammer.com *.officeapps.live.com *.office.com *.stream.azure-test.net *.microsoftstream.com;",
        "MicrosoftSharePointTeamServices": "16.0.0.21722",
        "X-Content-Type-Options": "nosniff",
        "X-MS-InvokeApp": "1; RequireReadOnly",
        "Timing-Allow-Origin": "*",
        "x-ms-apihub-cached-response": "true",
        "Cache-Control": "max-age=0, private",
        "Date": "Mon, 04 Oct 2021 09:24:15 GMT",
        "Location": "<redacted>",
        "P3P": "CP=\"ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI\"",
        "X-AspNet-Version": "4.0.30319",
        "X-Powered-By": "ASP.NET",
        "Content-Type": "application/json; charset=utf-8",
        "Expires": "Sun, 19 Sep 2021 09:24:15 GMT",
        "Last-Modified": "Mon, 04 Oct 2021 09:24:15 GMT",
        "Content-Length": "1808"
    },
    "body": {
        "@odata.etag": "\"1\"",
        "ItemInternalId": "4",
        "ID": 4,
        "Title": "Created",
        "Modified": "2021-10-04T09:24:14Z",
        "Created": "2021-10-04T09:24:14Z",
        "Author": {
            "@odata.type": "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
            "Claims": "i:0#.f|membership|manuel@manueltgomes.com",
            "DisplayName": "Manuel Gomes",
            "Email": "manuel@manueltgomes.com",
            "Picture": "https://manueltgomescom.sharepoint.com/sites/Test/_layouts/15/UserPhoto.aspx?Size=L&AccountName=manuel@manueltgomes.com",
            "Department": null,
            "JobTitle": null
        },
        "Author#Claims": "i:0#.f|membership|manuel@manueltgomes.com",
        "Editor": {
            "@odata.type": "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
            "Claims": "i:0#.f|membership|manuel@manueltgomes.com",
            "DisplayName": "Manuel Gomes",
            "Email": "manuel@manueltgomes.com",
            "Picture": "https://manueltgomescom.sharepoint.com/sites/Test/_layouts/15/UserPhoto.aspx?Size=L&AccountName=manuel@manueltgomes.com",
            "Department": null,
            "JobTitle": null
        },
        "Editor#Claims": "i:0#.f|membership|manuel@manueltgomes.com",
        "{Identifier}": "Lists%252fCreatedAndModified%252f4_.000",
        "{IsFolder}": false,
        "{Thumbnail}": {
            "Large": null,
            "Medium": null,
            "Small": null
        },
        "{Link}": "<redacted>",
        "{Name}": "Created",
        "{FilenameWithExtension}": "Created",
        "{Path}": "Lists/CreatedAndModified/",
        "{FullPath}": "Lists/CreatedAndModified/4_.000",
        "{HasAttachments}": false,
        "{VersionNumber}": "1.0",
        "{TriggerWindowStartToken}": "<redacter>",
        "{TriggerWindowEndToken}": "<redacted>"
    }
}

A lot is happening here, but we only need to focus on the “body” part. It’s similar to other everyday actions like the “Get items” action . We’ll get all columns from the SharePoint list, unless you limit the results with a view.

Limitations

Although Microsoft is quite clear on the behavior, I think it’s configuring to allow to pick views without filtering the data. The label is clear “Limit Columns by View” but I think it would be amazing to have a filtered list and only trigger if the elements of that list were updated.

Recommendations

Here are some things to keep in mind.

Always pick from the list

Always pick the site address and the list name from the list. You can define them manually, but there’s no added value.

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. 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.

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 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 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 datapoint instead of multiple simultaneously is a lot 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.

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 Trigger Reference.

Photo by Scott Evans on Unsplash

 

Manuel Gomes

I'm a previous Project Manager, and Developer now focused on delivering quality articles and projects here on the site. I've worked in the past for companies like Bayer, Sybase (now SAP), and Pestana Hotel Group and using that knowledge to help you automate your daily tasks

View all posts by Manuel Gomes →

Leave a Reply

Your email address will not be published.