Not sure if this is a bug, but it seems that named variables (via withName), at least in some cases, cannot have members referenced.
For example given a table “Some Table” that has a Name column:
withName([Some Table].First(), first_row, first_row.Name)
…fails at runtime as Name column cannot be found on the row, for some reason.
Thank you!
[UPDATE]
View below thread and coda doc bug example with RunActions.
Hello @Ed_Liveikis
I tried it (on the canvas) 4 different ways and it always works:
WithName(Results.first(),R,R.Name) → Susan
WithName(Results,R,R.first().Name) → Susan
Results.WithName(R,R.first().Name) → Susan
Results.First().WithName(R,R.Name) → Susan
I also tried it on another table or another column and it still works. Must be something other than just the formula I guess.
Hm yea, sorry should have tested the simple case first. But I’m seeing the same in the simplified version. The place I saw this bug was in a complicated formula with multiple scopes (runActions(, formulaMap, modifyRows(), so maybe it was something to do with that. I’ll try to reproduce at some point in that more complicated example.
OK - it is indeed easy to make a mistake somewhere else. We use nested WithName, formulamap and runactions on a daily basis and it can take some time to debug, but we have always gotten it to work.
Hi @joost_mineur , thanks.
It looks like I’ve been able to reproduce it in a simple case, and it appears to be caused by RunActions, although it’s possible other nested/scoped cases aren’t working:
you’ll have to make this editable (or publish it) for us to be able to click the buttons and change values
Hi @Ed_Liveikis ,
I think you are right.
I slightly changed the document (its copy, actually), to make it easier to test other options:
I definitely see it as a bug.
Just to bring the attention back as it’s having some impact.
Thank you 
Hello Everyone,
You should no longer see this issue after reloading your documents. We have also identified and fixed the testing gap that let this regression slip through. If you would like to know more about what happened please read on.
The connection between the formula engine and action engine is a bit complicated. The RunActions formula creates a transition boundary between the two engines, so we have to package up all data in the formula’s execution context and pass it to the action engine so it can execute the nested formulas with all of the outer information.
A recent document upgrade changed how we stored RunAction formulas so that we could more quickly push out optimization changes for those formulas. It turns out that the previous formula storage was rewritten in such a way that didn’t trigger some of our normal formula validation rules, most notably valid Row.Column dereferences. When this change rolled out we exposed the fact that not all context captured by the RunActions boundary was being passed to our compiler even though it was already being passed to our formula execution, which is why existing actions started failing when trying to compile and execute their nested formulas.
Sorry about the regression. Please let me know if you are still experiencing any issues.
@Jason_Tamulonis ,
thank you so much for the fix - and the full explanation!
Much appreciated
Thanks for the update Jason! Glad to see it fixed quickly and that the team is adding detailed tests! 
For the sake of consistency, I changed a bit the document inspired by @Ed_Liveikis (Coda Bugs) and built a simple test suite:
I’d love to hear your opinions to start a productive way to keep docs tested.
Thank you!
I’d wager they have a pretty sophisticated test suite and that what we did (by giving the team a sample doc demonstrating the error) was pretty much the perfect approach. I don’t think we need to be doing their regression testing for them. (though I’m open to being told otherwise)
Hi @Connor_McCormick,
I totally agree with you!
However, this regression exposed me with my clients and I wish I could have my own test suite to check if my app (doc…) is somehow in a healthy state.
So I was just collecting ideas if this does make sense, how this could be done and maybe some sanity check template might be foreseen in the future.
Ah, yeah that makes a lot of sense! I would also like to know if the problem is with me or is a bug (and maybe that way we could catch the errors sooner)