As part of my SharePoint connector series, I had a look at the When an item is created and the When an item is created or modified triggers in this post.
When and item is created
Table of Contents
Then when an item is created trigger may sound like the trigger that you want to use when new items created in a list need to trigger your flow. However you might want to think twice. Later in this post I will tell you why.
First I would like to have a look at the When an item is created action. Most of the configuration steps available are simple.
You can select a site and then a list and if you want to reduce the data collected, you could restrict the columns supplied by this trigger by selecting a view. Quite often the Limit columns By View settings is kept to the default of Use all columns.
Then comes the Recurrence setting. This is slightly more complicated.
Recurrence settings on the When an item is created
The recurrence setting gives an opportunity to make the flow check at a configurable interval. However this setting cannot be set to less than 15 seconds. If you try to set this below 10 seconds you will be shown the following error when you attempt to save your flow:
Flow save failed with code ‘InvalidWorkflowTriggerRecurrence’ and message ‘The recurrence trigger ‘When_an_item_is_created’ interval value ’10’ is not valid with frequency ‘Second’. The recurrence frequency cannot be less than ’00:00:15′.’.
In general I have found anyway that the flows will only really trigger every 1 minute. So this is not the option if you need instant responses. The Microsoft Graph subscription model will be a better option for that.
When an item is created or modified trigger
Now both the When an item is created and the When an item is created or modified trigger are fairly similar. Other than the obvious trigger reasons of course.
Now imagine that we have created a flow with many steps. ( In my example below I only have 1 step following the trigger:
And now my compose step is using taking the ID of the When an item is created trigger. The compose step represents my many steps in my flow.
The flow is working as expected and then one of those annoying people is going to ask you to adjust the flow and to make sure that the flow is triggered when items are modified as well.
In short we used the wrong trigger. Just replace that trigger? Well if we do that our flow will now not understand the ID property anymore and therefore this is removed.
In a similar way we could have the same issue if we had used the When am item or file is modified and we need the same for created items of course.
Hence the When an item is created or modified trigger is often the better option. But what if we want to make sure that the flow only triggers on creation or modification of the items?
To ensure that the flow only triggers when a new item is created while using the When an item is created or modified trigger just configure the trigger condition as shown below:
@equals(triggerBody().Modified, triggerBody().Created)Now we have the flow that behaves in a similar way to our original flow. However when the requirements change we can just adjust the trigger condition of our flow.
Discover more from SharePains
Subscribe to get the latest posts sent to your email.
The problem is Created and Modified SOMETIMES are not the same at the time of item creation. I observed this many times using “Created or Modified” trigger. The difference in time between these two columns is very very small that these columns fail to satisfy the condition. For that reason I still prefer Created over Created or Modified trigger.
If you find those small changes you could also check the difference rather than using equals. The sometimes unexpected change of requirements is often still a major piece of work as it means rebuilding the whole flow.
Thanks for sharing. Nice tip.
But… Using the trigger “When an item is created or modified” can be tricky if you are modifying the created or modified item. Then you can expect the flow will run again and again in an endless loop triggering itself.
To avoid the situation, I check what has changed. If nothing, I terminate the flow which breaks the recurrence.
That is exactly what the trigger condition will avoid. Typically you would add status fields.