Thank you for your feedback. Since table locking is not a security/permissioning feature, we haven’t prioritized the ability to restrict visibility of certain tables/rows.
However, I totally understand that having restricted visibility could be impactful for the use cases you described. Your feedback is noted, and I’ll pass it to the Product team as well!
Thank you so much for the feedback and suggestion here! For the time being, we don’t plan to make this feature available for Free/Pro plans. But if that changes, I’ll definitely let you know.
Yes, an add row button can be created by the maker to allow users to add rows to a locked table in a more controlled manner.
@Harshita_Yerramreddy1 - so, I definitely thought I would not use this feature. But turns out, I am using it all the time…just as an extra protection for myself and now to create pages where folks have more canvas control with databases having protection.
So just wanted to say thank you for all the work you and your team put into this!!
I just found another use case where table locking is not respected.
Table A contains a linked relation column to Table B. In Table A detail view the linked relation is displayed as a table.
If Table B is completely locked, nothing is editable from Table A detail view 
If Table B is partially unlocked to allow adding new rows,
then from Table A detail view Table B values can be added , can’t be deleted , can be edited 
.
@Harshita_Yerramreddy1 please take a look at this bug.
Very useful update
it would be nice if we could lock only certain columns
As well the already mentioned, edit but not add or only edit the added by the user, as well for each column
I keep thinking about these options being a column type that allows updating permissions across users, pages or rows.
Say for example you have a employee table, a projects table and a customers table. In each of these tables you may decide that a certain project can’t be modified because maybe it’s in contract. And because it’s in contract that customers info is also locked. But maybe you want some of your employees should be able to change all these parameters.
Letting people decide what type of things can be locked throughout a doc will help simplify the process. This way you can keep 1 page with all the locking controls tables instead of having to manage locking controls for every table throughout the doc.
Thanks for your effort—it’s good to see some progress in this direction. However, this feels like a missed opportunity to address a long-standing community need.
You’ve seen various requests from the community for granular locking: by column, by row, by user groups, etc. I believe this is a classic case where end users clearly understand their desired outcomes but struggle to generalize them into a universal implementation.
My thesis is simple: 99% of what users need from table-level locking has been right in front of us all along. We just need… conditional cell locking.
Yes, you could literally copy/paste the UI we know and love from Conditional Formatting and have it lock cells from editing when the formula evaluates to true. Hec, you might not even need new UI—just make “locked for editing” a new format that can be applied through conditional formatting, just like “italic” and “bold” (if you’re feeling particularly DRY).
Consider the advantages:
Conditional formatting applies cell by cell
Allows application to multiple columns or entire tables
Supports formulas
Works at the view level, enabling different locking rules per view
Can inherit from the source table or be redefined for specific views, depending on business needs
I’m confident that conditional locking could solve virtually any use case the community has raised. Happy to demonstrate how it would work for any specific scenarios people can think of.
An alternative I’ve advocated for years is to Make “Disable If” available to all columns, not just buttons. While this would achieve similar outcomes, conditional locking (or locking as a conditional format) might be an even more intuitive and powerful solution as it can be applied to multiple columns or an entire table at once.
Here’s hoping this finds receptive ears. We don’t need more setting toggles—let’s leverage the existing powerful formula system that makes Coda special !
What a great idea! You have my +1
Quite a good idea! +1 from me
Already can imagine how I could easily build a permissions table with locking parameters/formulas which are then referenced from this Conditional cell locking section in the settings and with that easily build permission profiles for column, row, table, page levels and all of a sudden we have user profile permissions.
If similar could be applied with hiding content would move Coda to a whole new level 
