Today we’re excited to announce Locking. It’s a new way for makers to stay in control of their docs, and offer a cleaner, focused experience for your contributors. Now you can choose exactly what type of changes you want teammates to make (or not make).
What we learned from you
Our starting point for Locking was a frequent piece of feedback from our makers. It usually sounded something like, ‘someone who didn’t understand a doc made a change that they weren’t supposed to.’
Sometimes the changes were fairly minor, like changing the width of a column you’d set just right. Other times it was more impactful, like changing a filter on a table. And sometimes it made us cringe, like a critical table being deleted. While most of these cases were innocent and accidental, they were often disruptive.
We also heard from a lot of makers who want to set permissions, explaining that not everyone needs full control to make every type of change. For example, docs that contain many tables, where specific contributors are tasked with adding data to a single central table.
And lastly, makers also described challenges their team members sometimes face as they start to use Coda. In these cases, we heard that occasionally the teammates didn’t need to help configure the doc, instead they could simply use it. For example, your teammates don’t need to see configuration icons on tables that are already set up for them. Or tooltips suggesting they right-click to configure a button, when all they need to do is push that button.
After listening closely and unpacking a diverse set of feedback, we set off to address these needs together. Our aim was to help makers prevent accidental changes, only allow teammates to make the changes they need, and remove distracting UI that they never need to see.
How it works
Instead of giving full control, you can now choose to lock a section so that teammates can only interact with its content ー disabling the ability to change settings like the filter on a table, or to add a new column or delete a view.
A sample doc with locking
As sections and docs vary in needs, you can choose the specific settings that are right for you. For example, you can set a section so that teammates can only make changes by pressing buttons you create. Or you can allow updating values in a table, but not adding new rows. If the text above a table is purely instructional, you can keep users from changing it.
You can also make an entire section read only. This is particularly useful for sections that store full tables of raw data, when you’ve already set up other focused views for teammates to see and change only what they need to.
Finally, you can also set the default for the whole doc, so once you’ve set everything up, all of the settings and configuration stay just as you intended. To see all the details, check out our
In many cases, all you really need is to prevent accidental changes and set the default experience so it’s clear what kind of typical changes are expected. But if someone wants to deliberately make further edits to improve the doc, that’s fine.
That’s what the default settings enable. Once you lock a section, no one can directly make restricted changes. But when needed, any editor can click the lock icon in the toolbar to temporarily unlock. Then, they can safely make any change, while the section remains locked for others.
This also applies to you as a maker, so that you don’t have to remember the difference between what you and others see. After all, you’re not always building the doc, and sometimes are using it just like everyone else. We’ve heard from many makers who were guilty themselves of making an accidental change, and this small speed-bump helps make sure you’re being deliberate.
Coming soon: Permissions
Beyond this, sometimes teammates should simply never make changes, other than those you intend. In the future, Permissions will allow you to limit those who can unlock a section or doc to just yourself, or a small group of people you choose.
We hope that Locking and Permissions can help your team work more efficiently, while you can relax confident that your doc will keep running just as you set it up. We’re always listening to feedback, and are eager to hear how you use locking, along with other needs you may have.
A friendly note on related features
While Locking allows you to restrict what changes teammates can make, we also hear a lot about needs to restrict what parts of a doc people can see. We think that
, also released today, can solve a related set of needs. If you prefer, you can now create separate docs for different audiences, while sharing and linking data between them.
Preventing accidental changes
Finally, while looking at the root cause of accidental changes, we realized some didn’t need locking at all. Certain actions that should be very deliberate were simply too easy. To address this issue, we recently made a handful of changes specifically to