Why Doesn't This Formula Work?

Formula is:

  AddRow([Table 1]),
  [lookup table 2]
      [Table 2].[Table 1 Inputs],
        [lookup table 2].[Table 1 Inputs].IsBlank(),
        [lookup table 2].[Table 1 Inputs].ListCombine(newrow)

It may be related to

and WithName() bugs

@Jason_Tamulonis, is this expected behavior?


Hi @cnr ,
Interesting case, but I’m not sure I completely understood it.
What is your purpose?

You say:

However, AddRow() formula returns an Action, not a row (*).

Therefore I expect that the quirky behaviour is due to the fact that the first time it adds the full row by guessing the data inference taking the origin of this action.

Let’s say that I’d expect an error, in this case, as we are comparing Action and Row (Ref) objects, but
I’d not consider it a bug (more on this from @Jason_Tamulonis and other @codans, I hope)

Also, I think it’s not related with the WithName() bug (now fixed): that was a due to a referential context not passed to RunActions() within WithName().

In the document I provided an example of how to refer to a newly created row.
I’m sure @Paul_Danyliuk (guess who… :slight_smile: ) fully explained about it but I cannot find the original post.
It is a typical use-case of opening the detail of a newly created row in a different table.
It still relies however on the “forced” way to create a row from an action, though.

As said sometimes in the past, I would open this topic.
I think that returning the subject of the action - rather than the actions itself - would be more useful and intuitive, as you pointed out with this post.
So add/modify/delete row should return the affected row(s) by simplifying significantly the logic of some typical use-cases.
Happy to discuss more about it.

@Federico_Stefanato This is a good explanation. We have discussed potentially changing this for WithName, but we have not had the bandwidth to get to it yet. We will have to spend some time thinking about if this could break existing workflows.

Turning the question around to the community. Are there places where changing this behavior would break existing flows? Do you feel like changing the behavior would be a better user experience?

Thank you for your response!

Is there even a way to call an action if it’s in a table? Can I add actions to various rows in a table and then call RunActions on them?

Also, isn’t it fairly inconsistent right now? For some reason the first AddRowis executed and then the second one is not? I would understand if it were both or neither, but as it stands it seems unpredictable.

Yes, this is my opinion as well.

I’ll try to extrapolate the topic to a new one and see how the community would see it.

Please, follow here:

1 Like