Most developers have tinkered with their trigger settings, but the documentation isn't great so we often leave some powerful functionality on the table.
In this blog I wanted to look at a few standard triggers, with most of the information transferable to others (Not all triggers will have all but I have not seen any that others have that these don't have).
The triggers I am looking at are
SharePoint - When an item is created or modified
Outlook 365- When a new email arrives (V3)'
On Button Press
This is a niche case but still useful to know. Default setting on split on trigger will mean that every item created or modified will trigger its own flow run. Turning this off will mean any outstanding items will be ran in one flow (so all the trigger inputs become an array instead of a single object).
When is this useful, well for starters Power Automate may feel like it is instant, but actually it is more of regular poll (this often depends on your license as to how often). You can see the poll time if you peak the code.
So there will be times when lots of changes, especially when you edit in grid view. Handling all changes in one flow can have its advantages, like knowing when to send a complete report.
We have already shown that we can either split on row/item or return an array. What we can also do is change what we split on (in some triggers but not all). SharePoint may not offer alternatives but Outlook on Mail received does.
As you can see, we can split on the value (email) or on attachments. Splitting on attachments could be a useful tigger, but no matter what I try I get errors.
And I think I know the issue, the split on is
when it should be
But even when I edit the trigger to the correct value (see how to here Creating a Power Automate Flow in Code)
I now get a type error.
This looks it might have been designed for Logic Apps where the schema is different.
This is a strange one, and is all due to Power Automate been built on logic apps. In logic apps you can split logging/tracking. By default it's by the same as the flow, but you can set the logs to split by nested arrays within the flow.
In other words, it's not something we can use unless we are tracking within Logic Apps. For more see here www.atomicscope.com
Securing your inputs and outputs will mean all data shown in the flow logs will be encrypted.
Inputs in this case will be the site name and list id, the outputs all the rows' data.
Retry is the same as any action step, with how many times you want the flow to retry.
The default is an exponential interval policy set to retry 4 times
Concurrency is the limit of parallel flows that can run at once. By default it is off, so in theory an infinite number of flows could run concurrently (e.g a million emails arrived on a 'email arrives trigger' would start 1 million flows simultaneously).
Setting to 1 would force each flow to run synchronously, this is could be important for 2 key reasons:
- Output order, I want the outputs in same order as inputs
- Throttling, if they all try to send an email simultaneously you might get throttled or worst (My outlook account got suspended because I tried to send 20 emails simultaneously, flagging me as sending spam)
Note: once turned on it cannot be turned off, so the maximum would become 100
And this is the most powerful (and probably most known). Conditions allow us to only run if a condition is met. This is great for saving api calls and keeping your logging clean and manageable.
We can one condition, or multiple, each is treated as an 'and'. But we can also use the 'or' expression within the trigger
The above has 3 conditions
- Wasn't Modified on a specific date
- Wasn't created (only modified)
- Day triggered wasn't Sunday
You can also use trigger condition on nested arrays by either
Or for all of them using String
As you can see there are a lot of power in using trigger settings, but also bugs/legacy Logic App inputs in the mix too that shouldn't be used.