cancel
Showing results for 
Search instead for 
Did you mean: 

Please have an option to get rid of the automatically applying the apply to each condition

I work for a forms company and we use logic apps to pump data into excel tables. We have a dynamic table option and if you add more than one row the flow with 'apply to each' will pump out each row fine, but it does this for each time a new row is added. i.e if there's 7 rows in a dynamic table and you try to add that to an excel sheet you end up with each row listed... 7 times for a total of 49 rows. I would be able to fix this with a do until loop, but because Microsoft feels the need to hold my hand it automatically applies the 'apply to each' condition before the loop. Please add an checkbox option to turn that feature on and off.

Status: New
Comments
Level 8

Hi @j_hermes, I think there's a different way to look at this that will alleviate your issue. Yes, when you add an array attributes as an input to an action, Flow will automatically nest that action within an Apply-to-each iterator, because it must. Until runtime, it has no way of knowing how many of those attributes it will be asked to handle, and, at runtime, it has no way to know if it should discard any "extra" information.

But we as Flow authors may know that the input array will always contain only one object (say, because of a top count of a 1 on a Get action, or because we've filtered our array - whatever the case may be). So, we can override Flow's insistence on an iterator. There are two approaches to this that I've been using recently:

1) Prepend each of my inputs with the first() expression. This tells Flow that only the first object (and therefore attribute) of an input array will be passed through that action. This might look something like:

ApplyToEachUservoice1.PNG

You can see that even though my "Filter Array" action body is still an array, Flow isn't trying to "hold my hand" because I'm telling it that the "Add a row[...]" action will only ever get one input. The big drawback here is that each input must have its array portion wrapped with first(). If I have many columns, it becomes visually confusing.

 

So, preferrable in many cases is

2) Use a Compose to apply first() to the array in advance, instead referencing the outputs of the Compose for each input, like so:
ApplyToEachUservoice2.PNG

Now, for each input in any following action, I need only point to attributes within "outputs('Compose_-_Apply_first()')" and what is being referenced by a token is more obvious, as seen with "outputs('Compose_-_Apply_first()')?['Email']" showing as "Email". This approach carries a bit of added risk though - Flow is always going to trust that you're giving it acceptable Compose outputs. It will never add an "Apply to each" but, if you're not careful, you could get a runtime errors, or unexpected inputs.

To you and all voters for this idea, be aware that Flow's insistence in adding "Apply to each" iterators should just serve as reminder that the number of inputs you've provided is undefined. Filtering look like true filtering (by ID or some other metadata) or by using Skip() to move to a different spot in the array , but by always filtering your inputs, and applying first() to the filtered array for each input (or filtering and using a Compose) you can supply inputs to your actions without the appearance of an iterator.

 

Hope this helps!
Josh