Trigger conditions does not stop from infinite trigger loop

[BennoWY]

Hi,

I have a Flow that runs on a SharePoint List. It must update a specific field in this list as soon as there is an added item or an old item is updated. The flow just hast two steps:

1. Trigger the flow by "When an item is created or modified"
2. "Update item" > Updates a specific field



The Flow runs from a service account. To to prevent infinite looping, I have set on the Trigger Step (1.) the following Trigger Condition:

@not(equals(triggerOutputs()?['body/Editor/Email'],'serviceaccount-email@domain.com'))

As I understood, this should prevent the flow to not run if the item was last updated by the service account itself.  Unfortunately, this does not work, and the flow is triggered regularly. What am I doing wrong or why does the flow run infinitely?

Really happy if someone can help!
Benno

[Pstork1]

I think your trigger condition syntax is a bit off.  Try the following:

@not(equals(triggerBody()?['Editor']?['Email'], 'serviceaccount-email@domain.com'))

[BennoWY]

Hi,
That doesn't change anything. The flow is still triggered the same way and loops.
By the way I used the formula editor to generate the syntax to hope I do no typing errors.

Rgds, 
Benno

[Pstork1 · Accepted solution]

Then I would check to make sure the flow triggers from and runs in the context of the service account.  Also check the accounts used on the connection. That trigger condition works fine in my testing.  You can check the trigger condition by adding a filter array after the trigger with the same condition.  Then after a run look at the input and output.  That should show you who the modified user is.

[BennoWY]

I found out what was the problem by testing with Editor/DisplayName instead of Editor/Email and then investigating the flow log.

When I used Editor/DisplayName in the trigger conditions it worked fine. If the service account does not have a license including e-mail service, the e-mail address of the service account is displayed, but the value of Editor/Email in the running flow stays null. This way the condition did not work.

Hm... what shall I say ... somehow a strange implementation concept. Thanks for the input to investigate the flow log.

[Pstork1]

Yes, if the service account doesn't actually have an email mailbox then there is no email to key off.

[BennoWY]

As i understand the concept, a mailbox is not enough (e.g. shared mailbox, group). it must be an account with a licensed mailbox where I can log in. 

[Pstork1]

Shared mailbox and group mailbox won't work because they aren't unique to the individual.  it's not the existence of the mailbox license.  Its the unique email address for the user that matters.  But to have that unique email address they need to have a license.  But you could have the license assigned without a mailbox and it still wouldn't work.

[BennoWY]

That's what I meat, a personal mailbox goes together with a license. 

[Pstork1]

Just trying to clarify that you can have the license without being assigned a mailbox.  Its the mailbox that counts, not the license.  Service accounts may be assigned an Office 365 license to give them access to other things like Power Apps or SharePoint, but if they don't have a mailbox they still won't work in your scenario using the email address.

[BennoWY]

That was always clear that a service account for Power Automate (PA) needs an appropriate license - unfortunately, I used PA license and not an M365 license, and exactly there was the problem and confusion. The PA accounts credential is an email address shown everywhere - but used in the trigger condition the value is null. Therefore, PA service accounts with a PA licensing do not really make sense in my point of view as flows often use email adresses.

Anyway, I learnad something.

[Pstork1]

The point is that its not the license that matters.  A service account with an Office license doesn't automatically get a mailbox.  The login is technically a User Principal Name which is normally, but not always, the same as the email address for a user.