Launched: Table Locking

[Harshita_Yerramreddy1]

We know users rely on Coda to store important data, whether it’s to track your company OKRs, project launches, or team wikis.

We’re excited to announce that Table Locking has launched today!

With Table Locking, makers can lock a table once, and have that locking respected across all connected views. Locking a table prevents structural changes, like deleting or modifying columns, and gives makers freedom to apply granular controls over who can add, edit, or delete row data.

As a collaborator, you’ll now have clear visual cues and guardrails, so you can view or contribute to tables without accidentally making unintentional changes.

How is this different from page locking?

Before, makers could prevent edits on a table by locking the page the table was on. However, this only locked the views on that page. So, in order to restrict edits in all views, makers have to manually lock each page that contains a view of a table.

Now, users can lock a base table or its view, which will lock all connected views across the entire doc. This provides additional peace-of-mind, and makes it easier to lock tables with critical information with just a few clicks.

How do I lock a table?

1. Select the table options.
2. Select table locking from the side panel.
3. Toggle on lock table and its views.
4. Toggle on additional desired settings, such as allowing collaborators to delete any rows.

Learn more about how to use table locking here: Lock tables and views | Coda Help Center

If you have any feedback on Table Locking, please share that in this form. Please note, this is a Team and Enterprise feature.

[Pablo_DV]

Awesome update, thank you very much!

This also opens up the possibility of having read-only and editable views in the same page, which was not possible before without work-arounds. Time to experiment!

[Tyler_Maskiewicz]

Thanks Harshita, this is great! I’d love to hear some example scenarios and use cases. I am trying to think through all the potential benefits, but know I am probably missing out on some great ideas by other makers.

Pondering:

• Add rows but NOT edit rows?
• Edit rows but NOT add rows?
• Pages as editable open surfaces where data tables can be locked? I’ve typically used canvas columns rather than granting page edibility.

I’d love to hear some folks other ideas.

[Karina_Mikhli]

Yes finally! This is going to give me so much more peace of mind.

[Harshita_Yerramreddy1]

Thanks Tyler, excited for you to use it! We’ve seen users in the Beta testing group use this for a wide range of scenarios. Everything from client billing to project trackers.

Here are some scenarios to answer your questions:

• Add rows but not edit rows: When these options are toggled, a user can add a row and edit any row they’ve added. For example, suppose you have a weekly standup table. Teammates can add a row to add their updates, without risking deleting or editing other teammates’ updates.
• Edit rows but not add rows: Suppose you have a launch calendar, where launch dates might be modified. A PMM might own adding critical launches, and can add those by unlocking the table for themselves. Once the table is locked, a PM can go in and just update launch dates if something slips.
• Pages as editable surfaces with locked tables: This is especially useful when a table might have many views across the document. To ensure peace of mind that collaborators won’t accidentally delete columns or modify a table view, you can lock the table (and all its views) while leaving page content editable.
  • A sample use case might be a collaborative Product Requirements Document, where there is a view of your team’s feature launch timeline. The timeline can be locked, while the contents in the PRD can be edited by the team.
• Besides this, table locking can always be used to add additional peace of mind for collaborative tables. This is especially useful if you have teammates who are new to Coda. This gives both you, as a Maker, and your teammates guardrails to prevent making accidental edits.

I’d love to hear more about how the community is planning to use this feature!

[Giuseppe_Covino]

This new feature is just for Team plan, I’d be useful to have a simplified table-locking (just a boolean all locked/nothing locked) for the free (or the pro) plan. Would it be possible?
thanks

[Tyler_Maskiewicz]

Thanks @Harshita_Yerramreddy1! This is super helpful for thinking through ideas. I appreciate the detail.

[Breno_Nunes]

It’s always nice to have new features.
Though, it would be great if you could lock tables with formula. It would be a game changing feature.

[Matthew_Strax-Haber]

This is awesome. I can’t wait to use it!

If you’re considering v2, here are a few requests:

1. Locking permissions for table views, not just the whole table.
2. “Row Open” buttons can choose a row Layout, not just a Table/View
3. Row Layouts have similar locking (view, modify, delete)

These three changes would (1) open a ton of use cases, and (2) simplify my formulas greatly as I currently use the following work-arounds:

1. “Read-Only” columns
2. Dummy table views that are just there to be linked to a layout
3. Multiple pages for different user roles that have different modification abilities

Stretch-goal: the ability to set a formula to determine whether a user can modify values in an editable column.

[Patrick_Kinsella1]

Awesome! This will be very useful.

[Adisorn_Sirisunhirun]

Is add rows disabling overcome by add row button.

[Alexandre_Tulet]

Great update!

However, locking the table on every page isn’t always ideal. Some views are meant for editing, while others are designed for presentation only — so it’s important to have flexibility.

It would also be awesome to have the ability to lock individual columns. Right now, I use formulas to prevent teammates from editing certain columns while allowing edits in others. But this approach can slow down large tables, so it’s not ideal.

It would be even better if column locking could be controlled by user — for example, using formulas. This would make access control much easier, without needing to create cross-docs, duplicate pages, etc. It would also allow automations to keep editing data while users can’t — which would be super helpful!

[Nikola_Lajic]

This is a welcome addition! Few notes tough.

If a page in the doc is unlocked anyone can add a /form pointing to the table and they will be able to add new rows. This makes locked tables vulnerable in unlocked docs.

As others have mentioned, it would be great to be able to leave a specific view of the table unlocked. With the current implementation we have to either keep the table unlocked + remember to lock each page where it shouldn’t be edited (has the same vulnerability as my first point), or lock the table for new rows but have it editable everywhere.

[Stefan_Stoyanov]

Thanks to @Harshita_Yerramreddy1 for sharing potential scenarios. There are not very often needed but I have few cases when that would be useful.

Hope this is just the start towards the much higher priorities

VS

[William_Devos]

It’s nice to see this improvement ship - thank you for delivering it and I hope you don’t mind me saying - a little overdue (but very grateful). However, I’d like to postulate that this delivers 75% of the industry standard, which is read, create, write, delete. The last three are covered - but I don’t think this covers a read or visibility permission? This is still a major use case for my clients who want to hide a singular table or its contents (e.g. HR grievances, payroll, salaries etc.) without the inertia of creating a whole separate doc. If this is possible and I have missed something please let me know.

Thank you.

[AJM]

what about locking so that rows cannot be expanded? I know we can just set the view to not show any other columns, but I still don’t like that people can accidentally open rows. it just looks messy.