Understanding CurrentValue and use of List().First()

It is hard for me to visualize this without having access to the doc. Mind sharing your setup either here publicly or privately with paul@codatricks.com?

The general rule of thumb is that you should avoid matching rows from different tables by values of some column, unless there are good reasons for that and you know what you’re doing (e.g. cross-doc scenarios or big data setups with need for archiving.) Instead you store references to other rows and read data from those references as needed.

Those two are the same, so no performance impact at all. CurrentValue is already there, just not displayed in your formula. By using it explicitly you just add yourself some clarity and disambiguation between thisRow.Column and CurrentValue.Column. BTW sometimes the formula editor would erroneously use the former instead of the latter, so your Column = thisRow.Column would actually be thisRow.Column = thisRow.Column, which is always true. Explicitly typing CurrentValue helps avoid this.

In your formula better type:

ListOfTasksTable.Filter(CurrentValue.TaskName.Find(“Submit”) != -1)

because Find returns a number (position of found substring or -1 if not found), and you don’t want any implicit conversion to boolean for that. I wouldn’t be sure that -1 auto-converted to false. AFAIK only 0 equals false, so you may have false trues. It’s another rule of thumb to not rely on implicit type conversions.

Comparing rows means comparing table/row IDs (text values basically). Comparing names from rows means reading those values from each row (dereferencing a column from a row) and also comparing text values. So even if your task names are unique, there’s still this added step of dereferencing a value from a row.

Also it seems like in your scenario (for a row in table A, rows in tables B and C are created when a button is clicked, and those rows correspond to that row in table A for the entire lifetime), it seems like you could ditch live Filter formulas entirely and simply save recently created rows into a Lookup cell of that row in table A. In your button you can do things like:

thisRow.ModifyRows(
  thisRow.RecordInTableB, TableB.AddRow(...),
  thisRow.RecordInTableC, TableC.AddRow(...)
)

i.e. — create a row in table B, create a row in table C, and save links to those rows into corresponding cells of thisRow where the button is clicked. Now that will be a performance boost because no cells will be unnecessarily recalculated when new rows are added to tables B and C.