I have a basic workflow which relates to a Sharepoint list with one text field and one (single select) choice field.
The workflow consists of:
Sharepoint Trigger - When an item is created or modified
Get item - using id from trigger
Condition statement - testing whether the "modified by email" was the system email account (under which I wrote the workflow)
If true then terminate
If false then update item
Prior to the new designer layout I have written all my workflows to test the "Modified by email" to avoid recursive loops and terminate the workflows and everything was fine, I could test the "Modified by in either the trigger or the Get item action. No problem.
However in the new designer world If I add a Get item action under the trigger it immediately wraps it in a "For each" loop, my condition statement then causes the workflow to fail with :
'The template language expression 'body('Get_item')?['Editor']?['Email']' cannot be evaluated because property 'Editor' cannot be selected. Array elements can only be selected using an integer index.
Alternatively if I point my condition statement to the modified by email field trigger then the designer encapsulates that into a for each loop and I can't subsequently have a terminate statement inside that.
I have tried switching to classic designer and it does exactly the same thing.
What has changed and how do we now go about avoiding recursive loops?
Many thanks
Hi @wskinnermctc , @Rhiassuring ,
I've tried both the Basic solution 1 and 2 and yes they both work in that they do not create the needless for each loops around a Get item or Update item action.
It's odd though that you would need to use the "split on" for the trigger as the trigger action should only be actioning one item and not an array (as i understand it the Split-on would cause a separate workflow instance for each item in hte array if there were any).
Surely the trigger "When an item is created or modified" should not be referencing an array in the first place.
Also it seems now that over this weekend the three dots in the top right hand corner has now changed to a toggle switch now enabling the creation of a workflow and immediately switching back to classic mode.
The trigger action pre
Omg, really? That's a great catch if that's the case, @wskinnermctc
The new designer and all the changes lately make it really difficult to pinpoint things. I'll look forward to seeing if your recommendation works for Ian.
This is kind of ridiculous, but I have found a difference depending on how the trigger is created. And/Or if you click Save.
I think the problem has to do with the "Done" button that no longer exists in the action settings. In classic view, you had to click Done when changing settings on an action. In Co-Pilot, you just switch between tabs so the flow doesn't really recognize the settings change.
So combine the issue of needing to turn on "Split On" when you have the trigger created automatically along with not having an Done button, the flow doesn't recognize the change.
Basic Solution 1:
Now the dynamic content is available and does not cause an For Each.
Basic Solution 2:
The Split On is automatically turned on when you manually create the trigger. The dynamic content is available and does not cause a For Each.
This is really silly
Well that's.. totally bizarre. I'm sorry that's happening. I've now tested my trigger condition twice, with the same outcome both times ... which isn't what you're getting at all!
@wskinnermctc @ScottShearer @David_MA any thoughts?
Thanks @Rhiassuring I understand about the scenarios. The code for the condition statement (after the trigger) works absolutely fine. (Though I still have superfluous for each loops around any further actions which reference the id in the trigger).
On the other scenario I pasted the code exactly as stated (but with my email) into the actual trigger condition in the settings on the trigger. Then went to the list and added a new entry. Returning to the Flow summary screen (see below) it reported an error with the flow trigger however still ran the flow and then the flow ran again (due to there being an update item action), ignored the trigger condition and was thrown out by the condition statement after the trigger.
So it basically ignored the condition within trigger settings
Looking at the flow checker it just says there is a problem with the trigger with a link to the trigger which takes me to a blank screen.
Hi @Ian_C - note that the formulas I posted are for 2 different scenarios. One for if you continue to use a condition, and one for if you user the trigger condition.
The trigger formula is this one:
@not(equals(triggerBody()?['value'][0]?['Editor/email'],'rhia@email.com'))
I've just double checked, and it's valid but what I have found, is that you can't "test" for it.
Like, if you set the trigger condition and then click "Test" and Automatically or Manual, it won't operate correctly. (Which I think is another thing that has changed lately, as I swear I used to test trigger conditions manually all the time..)
Save it, and go modify something in the library, and see if it runs. In my circumstance, it didn't run when I edited an item as myself, but it did run when Tom Hanks edited the item.
Thanks @Rhiassuring your code in the condition works so I can stop the recursive loops.
I tried putting your code into the trigger settings so that I wouldn't need the condition check
and it fails with
Unable to process template language expressions for action 'Condition' at line '0' and column '0': 'The template language expression 'triggerOutputs()?['body/value'][0]?['Editor/Email']' cannot be evaluated because property '0' cannot be selected.
This seems to indicate that the trigger is not returning an array however if you do a subsequent "Get Item" or "Update Item" referencing the ID from the trigger it puts the action within a "For each" loop - Most odd.
@Rhiassuring Thanks, the option to build from classic seems to be no longer available, selecting create automatically starts the new designer
That was happening to me as well (wanted to see what would happen if I switched with that flow.) I think you'd need to build it from scratch in Classic to not experience the weird "get item" situation.
@David_MA Thanks I tried switching back using the three dots however this still had the same effect.
It's like the Sharepoint Trigger - When an item is created or modified and the Get item action - using id from the trigger are returning arrays rather than the single item.