The discussion started here (Why Doesn't This Formula Work? by @Connor_McCormick and followed by @Jason_Tamulonis ), but perhaps it’s a good thing to give full visibility to a topic I consider an interesting point.
Have you ever had the need to refer to a just created/modified/deleted row(s)?
My current perception is actually that those formula are
Actions that return
My wish would be that those formulas would return the list of
Row references affected by the
The advantages I see are related to contextual and chained actions that would be more intuitive.
Think about something like:
// deleting/archiving Tasks.Filter([Done]).DeleteRows().FormulaMap( // delete completed tasks Archive.AddRow(currentValue) // for each one, put a row into the archive )
Note that there would be an implicit
To achieve the same, now it should be:
Tasks.Filter([Done]).withName(done, // filter completed tasks RunActions( done.FormulaMap( Archive.AddRow(currentValue) // for each task, put it into archive ), done.DeleteRows() // delete the list ) )
Or the very common:
// open a just created row in another table OpenWindow(Table.AddRow(...).ModalURL)
The current workaround leverages on a not fully consistent behaviour and it implies the need of a temporary column in the “generating” table.
I can provide more examples, if needed.
While I understand it’s not easy, I’d like to find out:
- if others would welcome this different perspective
- if it is realistically feasible from an implementation point of view
- if there could be side effects in existing documents whose logic specifically relies on this model
Happy to know your opinion!