flaky connector for shared flow

[JPMontoya]

Hi,

I have run into an issue with a flaky connector in a shared flow.

A bit of context: there are four components in play, 3 flows & 1 powerapp, which acts as a control-center of sort. In the app, data is entered by the user and the flows are run with that data. The 3 flows run sequentially (f1, f2, then f3), with each of them providing input for the subsequent flow. In Testing this whole construct for myself, I never experienced any kind of issue like this, the behaviour of the connector-actions was always consistent.

Now, to do a pilot-run of the whole thing, I shared both the 3 flows, as well as the PowerApp with a second user in our environment. Now the situation is as follows: If I run the whole thing, it uses my credentials to perform all the actions, it gets the files from my oneDrive, etc. When she runs it, it uses her credentials, uses her files etc. (as it should be).

However, in all of her runs, the action 'list rows present in a table' of the excel online for business connector is misbehaving. In the first flow it gets called with dynamically set inputs for Location, Document Library ID, FileID & TableID. The action works as expected and lists all the rows. This is done mostly to verify the dynamic inputs early.

In the third flow, the exact same action is used with the exact same inputs, but there she gets a 404.

As I mentioned, none of this happens when I run the flow. The Inputs are correct, I manually verified all of the IDs that are being used. I simply can't imagine what might cause such a behaviour.

The only thing that comes to mind is that for the third flow in her runs the excel connector somehow tries to access files on my oneDrive with IDs that have been identified (and verified in f1) on her oneDrive, so basically the connection not using her credentials but mine instead. I don't know however where I can check for such information and am quite generally at a loss as to what to do.

Any help, ideas or resources is very welcome

cheers,

JP

[JPMontoya]

Ok, I have done some experimenting with this on a tenant where I have access to multiple accounts. It seems that for whatever reason, when sharing the third flow, the connections don't switch over automatically from the "sharer's" connection to the connections of the person who received the flow (as can be seen in the screenshot, it doesn't use "my connections" from the point of view of the recipient of a shared flow).

This obviously is not exactly brilliant, as now all new recipients need to manually switch over all of their connections, which means that they either have to be guided through this or be given extensive instructions, as there are a lot of actions in this flow that use connections.

This is also not exclusive to Excel, as it turns out. It was just the first to be used and thus fail. All connections including Custom Connectors need to have their connections swapped.

If I had to make a guess I would say that this is either due to the size / complexity of the flow or alternatively due to the fact that the concurrency control of the trigger is set to 1 for this particular flow (seems less likely to me).

Therefore I have to wonder if anyone else has had a similar thing happen and if that is a known & expected behaviour.

cheers,

JP

[JPMontoya]

Update: scratch my second comment. First off, none of the other shared flows switch connections over to the ones of the recipient and they still work. Second off, actually switching the connections manually only breaks things further.

[rimatos]

Hi @JPMontoya ,

How are you ensuring that the Flows are being called in sequentially? Is it using Child Flows?

Additionally, would it be possible to show a screenshot of how you are inserting the data in the list rows action in the 3rd Flow which is misbehaving?

Regards,

Ricardo

[JPMontoya · Accepted solution]

Hi Ricardo (@rimatos)

Thanks for responding and sorry for the late reaction on my part, hectic times.

Regarding the sequencing. No I am not using Child Flows. I am using context-variables to store the responses from the previous flows. in that response there is a property that tracks whether the flow is successful, and only once that property equals 'true', the next flow will be launched. So e.g. the command for f2 to run looks like this:

If(_f1_response.success = "true", UpdateContext({_f2_response: f2.Run(...)}))

I have sort of figured out what caused the problem but I am not sure how to interpret my findings. Let me give some context:

In my post here I described an issue where my flow f3 (the one acting up with the excel-connector) always got triggered 4 times when the chain of flows was initiated from my PowerApp.

To fix this I attempted all the suggested fixes like duplicating the flow, removing and readding the flow to the PowerApp etc. but nothing worked. The final thing I tried was the 'Concurrency Control' for the trigger of the flow. This fixed the issue with the flow triggering multiple times.

However, it seems to me that the 'Concurrency Control' somehow messes with Connections in shared flows and causes the problem I described in the initial post in this thread. I duplicated my flow f3 and nuked basically everything except the one action that caused problems. Still, the issue remained. I then tried turning off the 'Concurrency Control' again, which is not possible. I then was able to reproduce the Connection issue (working for me, not working for whoever I share the flow with) in a different Tenant with a number of simple flows (consisting each only of a single action that uses a connection) by turning on 'Concurrency Control'. So this is not limited to just the Excel-Connector.

I then, rather annoyed I might add, spent a couple of hours recreating the troublesome flow from scratch without 'Concurrency Control' on the trigger, not running into either my initial issue with the multiple-runs getting triggered, nor this issue with connections not working when shared.

So ultimately it looks to me that my "fix" for the initial issue caused this particular problem. I can't however say that I'm entirely satisfied with this result as I don't understand

• why exactly concurrency control on the triggers causes such a connection issue with Teamflows
• why the initial problem with the quadruple-runs happened in the first place.

and I would quite like to avoid this happening to future flows of mine.

So in a way this topic can be closed I guess, since I quite frankly neither have the knowledge nor the time to investigate this any further. Still, if this is a known problem or the cause for the quadruple-runs is clear, then I'd obviously love to know to avoid future problems.

best regards,

JP

[rimatos]

Thank you for the reply on this @JPMontoya , it was very informative.

The best i can advise as of now would be if you face any of these mentioned issues in your Flow to raise a Support ticket through https://admin.powerplatform.microsoft.com/support, so we can troubleshoot this in more detail and understand what can be causing the issue.

Unless we have a working repro of the issue and/or an error message to continue it is a sensitive issue to troubleshoot.

Hope this helps!

Regards,

Ricardo