New designer issue - Avoiding recursive loops

[Ian_C]

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

[Rhiassuring]

Try this as the expression in your condition. No need to "Get Item". 

triggerOutputs()?['body/value'][0]?['Editor/Email']

Or,  you could just use it as a trigger condition (available through the Settings in the Trigger) and forego the condition in the flow entirely: 

@not(equals(triggerBody()?['value'][0]?['Editor/email'],'rhia@email.com'))

This means it will only run if the Modified By is NOT "rhia@email.com".

[David_MA]

If one of @Rhiassuring's suggestions does not work, you can switch to the old designer by clicking on the three dots at the top-right of the screen:

Of course, I don't know how long this will be allowed until we're all forced to use the new designer. Are you enjoying the new designer? It seems like a step backward to me.

[wskinnermctc]

@Ian_C Why do you need to use a "Get Item" action? The outputs should be the same for the trigger as the Get Item. Seems to be redundant.

Doesn't solve your apply to each issue, but curious about needing to use Get Item.

[Ian_C]

@wskinnermctc Hi, I used the "Get item" action on occasion where I've needed to change the trigger, plus it also makes for easier visual debugging.

[Ian_C]

@Rhiassuring Thanks I'll give this a go and report back

[Ian_C]

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

[Rhiassuring]

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.

[Ian_C]

@Rhiassuring Thanks, the option to build from classic seems to be no longer available, selecting create automatically starts the new designer

[Ian_C]

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]

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.

[Ian_C]

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.

[Rhiassuring]

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?

[wskinnermctc]

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:

• Create Brand New Flow with trigger "When an item is created or modified"
• Go to the Trigger settings, you need to turn the "Split On" to On and use the dropdown to select body/value.
• Then add a Compose step and type any text in the field so it's not empty.
• Then click Save

Now the dynamic content is available and does not cause an For Each.

Basic Solution 2:

• Create Brand New Flow with trigger "When an item is created or modified"
• Delete the Trigger
• Re-Add the trigger "When an item is created or modified"

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

[Rhiassuring]

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.

[Ian_C]

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