Kudos Mike. Good demo. Concurrency does not prevent trigger loops but I like the fact you included it to show what other types of control we have to reduce our monthly API execution calls being used up. Good man !! I've subscribed. :-D
Stephan, can you clarify what you mean by Type? In this video we use the Send HTTP Request to SharePoint action. The Method and content headers were set (content-type, if-match, x-http-method).
Very interesting video. It looks fantastic. It works with my "own" approval process, but I have a request, because it doesn't work in 1 condition. When I upload a file with same name and overwrite, the flow doesn't start again and file remains as APPROVED without proceeding approval process. Do you know any way to do it? Thanks in advance.
I think I would point you back at your trigger condition. If you're using "REQUEST POLICY APPROVAL" as a value in a field to trigger your flow, then you need to first, reset this to "SOMETHING ELSE" once your flow has started. Then, if you need to start your flow again, you simply use whatever method you're using now to reset it to "REQUEST POLICY APPROVAL" and it should run again. Uploading and overwriting the file will not automatically reset this value, but presumably you're doing something to update that value, maybe the user sets it manually, or you're using a manually triggered flow from the list item to "start the process".
@@BulbDigital Well, I've seen that flow for creating trigger, is executed (REQUEST POLICY APPROVAL) but because the file was already APPROVED some time in the past, then flow goes to the part of the branch that it does nothing. I've been thinking how to avoid infinite loop but I can not succeed by the moment. Because if I force the flow to fix as i.ex. NEW status, it could happen a infinite loop again. Let me try...
Not sure what's going on - preventing the infinite loop there is basically the premise of the video :) I would encourage you to comb through the video along with the blog, go step by step, and see if something was missed. Outside of that you're welcome to stop by our next office hours and we'll see if we can get you unstuck! www.bulb.digital/office-hours
Thank you for the awesome video Mike! I am relatively new to the Power platform and am finding Power Automate to be pretty good. In your demo you show two different workflows 1. to trigger the HTTP Request when a file is added manually and then 2. when a file is modified. In my situation I am using "When an item is added or modified". Is there a way to apply the method your speaking about to fit my scenario? Love the various context added as well.
Thanks Chris! You can absolutely apply the same trigger conditions in the "item created or modified" scenario. I'm going to make an assumption that you're simply trying to stop subsequent runs of your flow for a given item using this method. You'll simply want to use a trigger condition in your flow similar to... @not(equals(triggerBody()?['ItemStatus'],'Processed')) Then, in your flow the next thing you need to do is set the ItemStatus property to "Processed". Then do the rest of your work. The trigger defined above simply is looking for items that are "not processed". Using that trigger and setting the ItemStatus to "Processed" should stop that trigger from firing again for the same item in both the created and modified scenarios. Hopefully I understood your question. Let us know.
@@BulbDigital Thank you for getting back to me concerning my looping issue. I created the trigger condition @not(equals(triggerOutputs()?['ApprovalStatus'],'Processed')) I have an Out of Office list where people can submit OoO approvals. People can enter when they will be out of office and who their workflow approval delegate is. Setting the flag "Run Workflow Now": Y/N field to "No" doesnt allow the workflow to run and allows the user to go back to the item and update any of the previously existing metadata. Once the data is updated and the flag is set to "Yes" the workflow will run. I have made the Approval Status field default to "Pending" on a new item entry. If the workflow runs properly and goes to the approval the list is updated "Approval Status" is set to Processed. What I am finding is that the workflow still loops and doesnt stop at the approval.
Hey Chris, I've sent your response to Mike to see if he has any thoughts right off the bat. If it's something that needs to be dug into, I'd recommend coming to our next office hours and we can see if we can help! www.bulb.digital/office-hours
Hi Mike I have a O365 Outlook flow where when a new message arrives in a shared mailbox > Mark as read or unread > reply to email. It runs well but the issue that I've run into is when the mailbox owner/sender of the message is equal to the recipient for the message, the flow gets stuck in a reply loop. I've tried to create a condition for this to terminate but it isn't working like id hope.
I think I'd ask to know a bit more about your the high level goal you're shooting for. It seems that there may be opportunity for a better approach if you're in a predicament where a user is sending e-mail to their self. In the video, we are using a SharePoint list which we have quite a bit more control over fields, values, and trigger actions. When checking a mailbox, there are certainly more limitations.
@@BulbDigital So the issue that I was having was that a mailbox owner received a message wherein they were cc'd. They inadvertently replied to themselves in reply all & set off a loop of auto responses. Im wondering if there was a way to set a condition for this? I have tried but ultimately i had to stop the flow altogether & restart.
Ok, that is helpful. I don't think that this can be solved with trigger conditions. I think you should add steps into your flow to parse the From, CC and possibly BCC addresses. You should look in these fields for "yourself" (shared mailbox address), and then remove it, and then send the reply. Also be sure to check that you're actually sending it to someone... e.g. if the shared mailbox address is the only one in the From address, and you remove it, then your flow will fail because there is nothing in the To address of the reply. Hope this is helpful.
Hi! Do you know how can I handle the trigger "When a file is modified (for onedrive)", but avoid the reload of the webpage is a trigger? Because I can handle it when a table is updated but when the webpage reloads (without changes), it triggers anyway. Thank you in advance
Can you provide a bit more detail for your scenario? More specifics on the webpage reload and how it relates to your OneDrive file trigger might help. Also wanted to note that if you'd like hands-on help, you're welcome to come by office hours! www.bulb.digital/office-hours
@@BulbDigital Thank you for your response. My scenario is: I have an excel online file within One Drive (for business) with a table (14 columns more or less) and I want to trigger it when someone update this table. My problem is that besides when someone make any change, also it triggers when the excel online file reloads, so I get triggered more than once. Thank you again.
That helps quite a bit. In your scenario there is no way to use a trigger condition or filter for only changes to the data within the Excel file. The trigger action you're using simply does not support it. My understanding of your scenario leads me to believe that there are probably some better approaches you could take. First, if you're having multiple users access and manipulate the Excel file in someone's OneDrive location, you may want to consider moving this file or the data to a better location like SharePoint or Microsoft Teams. Second, if you need better control over the trigger, I would recommend putting this data into a Microsoft List or a SharePoint List and triggering on when a list item is created or modified. You can then use trigger conditions to filter things out if you need to.
used this to trigger condition : @equals(triggerBody()?['zk_runtheflow'],'yes') Error:----- Cannot read properties of undefined (reading 'properties'). I am receiving this error. Can you help me with it?
Based on your question, I am going to assume that you're trying to use a Yes/No field type in SharePoint. If this is true, then your issue is in the value that you are checking. Instead of checking for 'yes' you should be checking for true. Either of these should work for the Yes/No column type in SharePoint. @equals(triggerBody()?['RunThisFlow']?['value'],true) or @equals(triggerBody()?['RunThisFlow'],true)
@@BulbDigitalMein is text data type in dataverse. I am will try your suggestion. I took a variable(V1) with text type in dataverse. in power apps, I kept the default value of that variable to yes. and change its value to no in Update row. I created a condition that V1 = yes, then run the flow.
Any idea on why Microsoft would change how workflows operate causing so much unnecessary coding? SharePoint 2010/2013 workflows do not trigger the same workflow when they change the underlying list.
SharePoint workflow was just that, workflow that is built into SharePoint. Power Automate is a cloud workflow solution that works with almost any source. Due to this many of the deep interactions that were built into SharePoint workflow simply does not exist. The benefit is that Power Automate works against a whole host of other data sources and actions.
@@BulbDigital Thanks for taking the time to respond. Your reasoning still begs the question: what is the use case that requires a flow to trigger itself when it's making changes to an item it's already working on. Seems like a solution for maybe one special Microsoft centric situation that now causes 1000's of people to have to compensate. I get that a work-around is not that difficult be there are far better ways to address this situation than what they did.
I understand how it is frustrating. The way you phrased your last question is makes the assumption someone had to build logic to make the Flow be triggered when it is making a change to the same SharePoint item that triggered the flow. When in fact it is the other way around. The simplest implementation, and what they have implemented, always triggers the flow regardless of what caused the trigger to occur. What Microsoft didn't do is build a process/component/feature that would allow you to automatically not trigger additional flows when you change the same item that was initially triggered. My guess is that implementing a feature like that would be quite complex and challenging. Especially since Flows are not part of SharePoint and are a separate technology. With all of this said, are you having an issue stopping multiple flows from running? If so, we could make some suggestions (and in fact a video we are working on will address one option).
@@BulbDigital We can agree to disagree. I dont think that it makes any logical sense to default to triggering a flow for a list item that the flow is already working on. Infinite loops should not be the norm. The fact that flows can sense the issue and puts out a warning is proof. Triggering again should have been the developer choice and not the default action. The need to no have infinite loops happen far outweighs the likely one or two use cases where it might make sense. As a result, Microsoft has triggered (like the pun) a Myriad of videos and posts on how to overcome the issue, most of which are cumbersome work-arounds. Make zero sense. But very typical for Microsoft.
@@iamintractable1805 Infinite loops are casued by unintention, not intention. What Mike has explained is no different to what developers check for in code loops in C#, VB, Python, etc. An example I use is when you use the "when an item/file is updated" and you update properties within that flow. For example a person fills in an Excel worksheet and saves the changes. The user's actions trigger a "When a file is updated" flow. Amongst other actions, one will updates a status property to show the work has reached the next stage. Maybe you want to pull the Excel data into certain columns. This in turn triggers a "When a file is updated" flow (itself). So you need a trigger condition to check for something that identifies if it was triggered by a person, or itself. You add a trigger condition to identify who actually triggered it, or how recent the trigger was, or any other identifiable value that can be used to prevent a loop. We use what we call "non-controlled accounts" which are unlicensed, to run SharePoint flows, In this example, we can add a trigger condition identify which account started the trigger and ignore those trigger by a "un-controlled" account. Example: ua-cam.com/video/Ovyjo0LOTi4/v-deo.html Sorry Mike for adding a link inside your video. I hate doing that but this supports your point of view. I can remove it once @I Am Intractable has seen it.
Kudos Mike. Good demo. Concurrency does not prevent trigger loops but I like the fact you included it to show what other types of control we have to reduce our monthly API execution calls being used up.
Good man !! I've subscribed. :-D
Thanks John! Appreciate the feedback.
This was very helpful, thank you.
You're welcome! Happy we could help 😊
Really Useful. Why didn't you have to specify the Type in your Send HTTP Requests?
Stephan, can you clarify what you mean by Type? In this video we use the Send HTTP Request to SharePoint action. The Method and content headers were set (content-type, if-match, x-http-method).
Thanks a lot...that was helpful
Happy to help!
Very interesting video. It looks fantastic. It works with my "own" approval process, but I have a request, because it doesn't work in 1 condition. When I upload a file with same name and overwrite, the flow doesn't start again and file remains as APPROVED without proceeding approval process. Do you know any way to do it? Thanks in advance.
Sorry, I miss one detail. I use as trigger for "REQUEST POLICIY APPROVAL" When a file is created or modified (properties only).
I think I would point you back at your trigger condition. If you're using "REQUEST POLICY APPROVAL" as a value in a field to trigger your flow, then you need to first, reset this to "SOMETHING ELSE" once your flow has started. Then, if you need to start your flow again, you simply use whatever method you're using now to reset it to "REQUEST POLICY APPROVAL" and it should run again. Uploading and overwriting the file will not automatically reset this value, but presumably you're doing something to update that value, maybe the user sets it manually, or you're using a manually triggered flow from the list item to "start the process".
@@BulbDigital Well, I've seen that flow for creating trigger, is executed (REQUEST POLICY APPROVAL) but because the file was already APPROVED some time in the past, then flow goes to the part of the branch that it does nothing. I've been thinking how to avoid infinite loop but I can not succeed by the moment. Because if I force the flow to fix as i.ex. NEW status, it could happen a infinite loop again. Let me try...
It generates infinite loop if I add a change of Approval Status to NEW or something different than APPROVED or REJECTED. Now I'm quite lost....
Not sure what's going on - preventing the infinite loop there is basically the premise of the video :) I would encourage you to comb through the video along with the blog, go step by step, and see if something was missed. Outside of that you're welcome to stop by our next office hours and we'll see if we can get you unstuck!
www.bulb.digital/office-hours
Thank you for the awesome video Mike!
I am relatively new to the Power platform and am finding Power Automate to be pretty good.
In your demo you show two different workflows 1. to trigger the HTTP Request when a file is added manually and then 2. when a file is modified.
In my situation I am using "When an item is added or modified".
Is there a way to apply the method your speaking about to fit my scenario?
Love the various context added as well.
Thanks Chris! You can absolutely apply the same trigger conditions in the "item created or modified" scenario. I'm going to make an assumption that you're simply trying to stop subsequent runs of your flow for a given item using this method. You'll simply want to use a trigger condition in your flow similar to... @not(equals(triggerBody()?['ItemStatus'],'Processed'))
Then, in your flow the next thing you need to do is set the ItemStatus property to "Processed". Then do the rest of your work.
The trigger defined above simply is looking for items that are "not processed". Using that trigger and setting the ItemStatus to "Processed" should stop that trigger from firing again for the same item in both the created and modified scenarios.
Hopefully I understood your question. Let us know.
@@BulbDigital Thank you for getting back to me concerning my looping issue.
I created the trigger condition @not(equals(triggerOutputs()?['ApprovalStatus'],'Processed'))
I have an Out of Office list where people can submit OoO approvals.
People can enter when they will be out of office and who their workflow approval delegate is.
Setting the flag "Run Workflow Now": Y/N field to "No" doesnt allow the workflow to run and allows the user to go back to the item and update any of the previously existing metadata. Once the data is updated and the flag is set to "Yes" the workflow will run.
I have made the Approval Status field default to "Pending" on a new item entry.
If the workflow runs properly and goes to the approval the list is updated "Approval Status" is set to Processed.
What I am finding is that the workflow still loops and doesnt stop at the approval.
Hey Chris, I've sent your response to Mike to see if he has any thoughts right off the bat. If it's something that needs to be dug into, I'd recommend coming to our next office hours and we can see if we can help! www.bulb.digital/office-hours
@@BulbDigital Very good, thank you!
Hi Mike I have a O365 Outlook flow where when a new message arrives in a shared mailbox > Mark as read or unread > reply to email. It runs well but the issue that I've run into is when the mailbox owner/sender of the message is equal to the recipient for the message, the flow gets stuck in a reply loop. I've tried to create a condition for this to terminate but it isn't working like id hope.
I think I'd ask to know a bit more about your the high level goal you're shooting for. It seems that there may be opportunity for a better approach if you're in a predicament where a user is sending e-mail to their self. In the video, we are using a SharePoint list which we have quite a bit more control over fields, values, and trigger actions. When checking a mailbox, there are certainly more limitations.
@@BulbDigital why do my comments keep getting deleted?
This comment is the first we've seen from you/been notified of, so perhaps they weren't getting fully submitted by YT!
@@BulbDigital So the issue that I was having was that a mailbox owner received a message wherein they were cc'd. They inadvertently replied to themselves in reply all & set off a loop of auto responses. Im wondering if there was a way to set a condition for this? I have tried but ultimately i had to stop the flow altogether & restart.
Ok, that is helpful. I don't think that this can be solved with trigger conditions. I think you should add steps into your flow to parse the From, CC and possibly BCC addresses. You should look in these fields for "yourself" (shared mailbox address), and then remove it, and then send the reply. Also be sure to check that you're actually sending it to someone... e.g. if the shared mailbox address is the only one in the From address, and you remove it, then your flow will fail because there is nothing in the To address of the reply. Hope this is helpful.
Hi! Do you know how can I handle the trigger "When a file is modified (for onedrive)", but avoid the reload of the webpage is a trigger? Because I can handle it when a table is updated but when the webpage reloads (without changes), it triggers anyway. Thank you in advance
Can you provide a bit more detail for your scenario? More specifics on the webpage reload and how it relates to your OneDrive file trigger might help. Also wanted to note that if you'd like hands-on help, you're welcome to come by office hours! www.bulb.digital/office-hours
@@BulbDigital Thank you for your response. My scenario is: I have an excel online file within One Drive (for business) with a table (14 columns more or less) and I want to trigger it when someone update this table. My problem is that besides when someone make any change, also it triggers when the excel online file reloads, so I get triggered more than once. Thank you again.
That helps quite a bit. In your scenario there is no way to use a trigger condition or filter for only changes to the data within the Excel file. The trigger action you're using simply does not support it. My understanding of your scenario leads me to believe that there are probably some better approaches you could take. First, if you're having multiple users access and manipulate the Excel file in someone's OneDrive location, you may want to consider moving this file or the data to a better location like SharePoint or Microsoft Teams. Second, if you need better control over the trigger, I would recommend putting this data into a Microsoft List or a SharePoint List and triggering on when a list item is created or modified. You can then use trigger conditions to filter things out if you need to.
@@BulbDigital I will try to create this file in sharepoint to handle it better. Thank you very much for your help.
used this to trigger condition : @equals(triggerBody()?['zk_runtheflow'],'yes')
Error:----- Cannot read properties of undefined (reading 'properties'). I am receiving this error. Can you help me with it?
Based on your question, I am going to assume that you're trying to use a Yes/No field type in SharePoint. If this is true, then your issue is in the value that you are checking. Instead of checking for 'yes' you should be checking for true.
Either of these should work for the Yes/No column type in SharePoint.
@equals(triggerBody()?['RunThisFlow']?['value'],true)
or
@equals(triggerBody()?['RunThisFlow'],true)
@@BulbDigitalMein is text data type in dataverse.
I am will try your suggestion. I took a variable(V1) with text type in dataverse. in power apps, I kept the default value of that variable to yes. and change its value to no in Update row. I created a condition that V1 = yes, then run the flow.
Any idea on why Microsoft would change how workflows operate causing so much unnecessary coding? SharePoint 2010/2013 workflows do not trigger the same workflow when they change the underlying list.
SharePoint workflow was just that, workflow that is built into SharePoint. Power Automate is a cloud workflow solution that works with almost any source. Due to this many of the deep interactions that were built into SharePoint workflow simply does not exist. The benefit is that Power Automate works against a whole host of other data sources and actions.
@@BulbDigital Thanks for taking the time to respond. Your reasoning still begs the question: what is the use case that requires a flow to trigger itself when it's making changes to an item it's already working on. Seems like a solution for maybe one special Microsoft centric situation that now causes 1000's of people to have to compensate. I get that a work-around is not that difficult be there are far better ways to address this situation than what they did.
I understand how it is frustrating.
The way you phrased your last question is makes the assumption someone had to build logic to make the Flow be triggered when it is making a change to the same SharePoint item that triggered the flow. When in fact it is the other way around. The simplest implementation, and what they have implemented, always triggers the flow regardless of what caused the trigger to occur. What Microsoft didn't do is build a process/component/feature that would allow you to automatically not trigger additional flows when you change the same item that was initially triggered.
My guess is that implementing a feature like that would be quite complex and challenging. Especially since Flows are not part of SharePoint and are a separate technology.
With all of this said, are you having an issue stopping multiple flows from running? If so, we could make some suggestions (and in fact a video we are working on will address one option).
@@BulbDigital We can agree to disagree. I dont think that it makes any logical sense to default to triggering a flow for a list item that the flow is already working on. Infinite loops should not be the norm. The fact that flows can sense the issue and puts out a warning is proof. Triggering again should have been the developer choice and not the default action. The need to no have infinite loops happen far outweighs the likely one or two use cases where it might make sense. As a result, Microsoft has triggered (like the pun) a Myriad of videos and posts on how to overcome the issue, most of which are cumbersome work-arounds. Make zero sense. But very typical for Microsoft.
@@iamintractable1805 Infinite loops are casued by unintention, not intention. What Mike has explained is no different to what developers check for in code loops in C#, VB, Python, etc. An example I use is when you use the "when an item/file is updated" and you update properties within that flow. For example a person fills in an Excel worksheet and saves the changes. The user's actions trigger a "When a file is updated" flow. Amongst other actions, one will updates a status property to show the work has reached the next stage. Maybe you want to pull the Excel data into certain columns. This in turn triggers a "When a file is updated" flow (itself). So you need a trigger condition to check for something that identifies if it was triggered by a person, or itself. You add a trigger condition to identify who actually triggered it, or how recent the trigger was, or any other identifiable value that can be used to prevent a loop. We use what we call "non-controlled accounts" which are unlicensed, to run SharePoint flows, In this example, we can add a trigger condition identify which account started the trigger and ignore those trigger by a "un-controlled" account.
Example: ua-cam.com/video/Ovyjo0LOTi4/v-deo.html
Sorry Mike for adding a link inside your video. I hate doing that but this supports your point of view. I can remove it once @I Am Intractable has seen it.