When a user adds a row to a table, they can be either explicitly assigned–through user() by adding that value to the row–or extracted through a column formula, createdby(). In the end they both achieve the same outcome, which is knowing who that row pertains to, however the former is hard coded. Is one method considered best practice?
Instead of hardcoding the “createdBy” into a column, you can use the formula in the Value for new rows area.
That way you get the creator of the row but in an editable fashion
I prefer this as inputting with User() only works if you are adding rows via button but the Value for new rows route would apply when rows are added manually in the table, through automations, through buttons, etc.
Thanks @Scott_Collier-Weir - makes perfect sense.
On a related issue, let’s say I have a table dbEmployees that ties the employee’s name to their role and their billable rate for estimating purposes. (The employee in this case is of column type People). When an employee adds a row—per your recommendation above—their name is added to the Employee column of dbTimeTracking.
There are a number of ways to set this column up – a lookup to dbEmployees, Text or People (all with a value for new rows of user()). Can you clarify for me the pros/cons of each approach and/or explain what is considered best practice for this scenario? In watching @Paul_Danyliuk’s INCREDIBLY helpful Best Practices Showcase videos, I got the sense that, at the time, he possibly recommended against them based on how he set up that file. That said, it was some time ago and at the rate Coda changes, it would not surprise me if methods have evolved as well. (Commenting him here as well, should he care to shed some light on his preferred methodology.)
Thanks for pinging me.
The screenshots are from the dbTimeTracking table, correct? In any case, only one of these is correct.
User() returns a value of a type Person. So while you can technically set any value onto any typed column, the proper way to place it is in the column of type People (i.e. the last screenshot). Text type columns are basically the “any type” columns, so technically it’s not wrong to put a User() object there, but you won’t get any benefits of it either.
But none of these things are what you want to do. Since you’ve created yourself a dbEmployees table, you probably want to link to that. So you set up your Employee column as a lookup to dbEmployees, but in your Value for new rows you set not just the User() but, e.g.
dbEmployees.Filter(CurrentValue.People= User()).First()
so that you’re inserting a row from dbEmployees into every cell of the dbEmployees-typed column, and that row is found as the one having the Coda User in its People column.
Hope this makes sense. And thanks for the compliment 
On the original topic, it depends on what you need. The CreatedBy() formula — it’s a formula meaning you cannot override it for individual rows. This means, if you’re using CreatedBy() to calculate the assignee and you want to reassign a task, tough luck because you cannot change who created the row. Hence, using an editable (non-formula) column with an auto-populated value could be a preferred strategy here.
1 Like
Thanks @Paul_Danyliuk – That’s exactly the information I was looking for.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.