Outlook event added, updated or deleted triggering multiple times

[Anonymous]

Hi everyone, does anyone have any suggestions why the Office 365 Outlook trigger for "when an event is added, updated or deleted (V3)" would be triggering multiple times event for the same event?

e.g. I create an event on the calendar, the flow runs twice (receiving the 'addded' action type each time). Similarly if I update an event (with the 'updated' action type). If I delete an event it's a little different, one run sees the 'updated' action type and the second is 'deleted'.

Not sure where to look next so all help welcome. Thanks.

[v-duann-msft]

Hi @Anonymous 

Thank you for posting.

According to your description, you would get two flow results while using ‘when an event is added, updated or deleted (V3)’ action. If any misunderstanding, please kindly let me know.

I tested and the get the exactly same result as yours. When I analyze the flow log, I notice the tags for these three operations are separated.

Thus, this should be product limitation for this action. Although I can see two processing in run history for the same event ,but I will only receive one result if I add send email/post message action after ‘when an event is added, updated or deleted (V3)’. I believe the flow run only once but the calendar graph API called twice. So wo got this weird behavior.

If you don’t want get the history twice. I recommend you use ‘When a new event is created (V3) ’; ‘When an event is modified (V3)’ separately instead. It will generate flow history once.

https://docs.microsoft.com/en-us/connectors/office365/

Hope the content above may help you.

Thanks

Anna

[Anonymous]

Thanks @v-duann-msft for the thoughtful reply. Unfortunately I don't think using the added and updated triggers will capture the 'deleted' event.

That said, I'm now receiving notifications on the original trigger very intermittently. Something strange is going on for sure. I've contacted support, will see what they have to say.

[obmb]

Anyone has solutions for this issue? I have the same issue 

[ericwhitley]

The duplicate triggers for New Events (ActionType = "added") is one of many bugs with this connector.  In my case it happens about 20% of the time and the "Date" value is always exactly the same.  This connector no longer gives us the "lastModifiedDateTime" property either so there's no way to tell which is more recent. And when the two triggers come in, almost all of their properties are the same except the "id".  But the "iCalUId" property is the same.

Here's what I'm doing to avoid creating duplicates in my destination site:

1. Add a Delay for a random amount of seconds before searching for an existing entry in the destination site. This allows one of them to be processed ahead of the other since they came in at the same time:     rand(5,60)

2. Search for a matching request by iCalUId:      iCalUID eq 'triggerOutputs()?['body/iCalUId']'

3. For Single day events that will return an exact match.  For Recurring events the iCalUId property is the same, so this returns a list of items.  You need to compare the Start and End times to ensure its the entry you want. But the format of the date field in Sharepoint is different than what's returned by the connector so you have to format them equally:

formatDateTime(triggerOutputs()?['body/startWithTimeZone'], 'MM-dd-yyyy HH:mm:ss tt') is equal to formatDateTime(items('Apply_to_each')?['StartDateTime'], 'MM-dd-yyyy HH:mm:ss tt')

AND

formatDateTime(triggerOutputs()?['body/endWithTimeZone'], 'MM-dd-yyyy HH:mm:ss tt') is equal to formatDateTime(items('Apply_to_each')?['EndDateTime'], 'MM-dd-yyyy HH:mm:ss tt')

(You may need to change the 'Apply to each' , 'StartDateTime' and 'EndDateTime' references.)

Now the hard part:

4. We need to figure out which trigger is the most current.  For that we compare the "id" of the trigger versus the one we stored in our destination site. (I created a field called "eventId" to store this value.)

triggerOutputs()?['body/id'] is greater than items('Apply_to_each')?['eventId']

** This is a mere text comparison and it actually works most of the time, but not 100%. I need to figure out how to convert the id's to numeric values to do that. Any ideas?

If the current event is more recent than the existing one we found, then update it.

[ericwhitley]

I've noticed up to 4 "update" triggers from a single manual change in outlook.  And in some cases we'll get multiple triggers without any manual changes.  This is documented as "internal Exchange processing" in the Connector help:

https://docs.microsoft.com/en-us/connectors/office365/

The help also says we should be able to use the ActionType property to "ignore unnecessary updates".  But almost everything comes in as "update" so how do we know if it's a manual change or just internal processing? Is there another indicator returned by the connector that I'm missing?

[ericwhitley]

I added a workaround, see above.

[D_i_G_i_T]

Well I was looking for a solution to my problem but I can see that this error is running for more than a year now. It's incredible.

What you can do to prevent the concurrency and having to manage which running flow is the right one, is to disable the trigger concurrency in its settings.

[drkmccy]

This connector is either getting updated without versioning or there are changes happening in Exchange that are now contrary to several posts above. I find the following:

• Turning off concurrency control or dropping it to 1 does not resolve it.
• The id as well as the iCalUId stay the same
• lastModifiedDateTime is there although I can't see how this could be used in a trigger condition

I think what needs to happen is that MS should not let Exchange online pass through to Power Automate until it's done with its internal processing so it passes through a single added, modified or deleted event. Surely if should know that if it needs to do processing on it then it's not ready to be used in a flow?

[ericwhitley]

Exactly! The problem is with Outlook/Exchange triggering the connector to run when it's unnecessary.  I wish MS would fix this.

[Blackpajamas]

I've been struggling with this sam issue for some time now. Has anyone found a solid work around or had any indication that MS is aware of this and working on a fix?

[Benki0815]

That did the trick. Setting the trigger concurrency to 1 prevents the trigger from firing twice!