At Coda, we enjoy uncovering simple ways to help make your docs look (and feel) sharp, clean, and clear. Case in point: our two new updates—improved in-doc search and better linking to other Coda docs.
In-doc search improvements.
Let’s start with a centralized, unified search. Previously, your in-doc search was hidden in the lefthand page navigations, which meant more time searching for search rather than getting started.
On top of not having to hunt to start your search anymore, you now have more space to see your results in an expanded search modal, making search results easier to navigate. You’ll also experience more accurate and relevant search results, as well as easily filter these results by workspace, doc, page, and building block from the expanded search modal. Plus, we’ve minimized trial-and-error thanks to search previews that show more information without clicking through, so you can make your first click, the last click.
Try the new search by:
Navigate to the top of any doc or dashboard in Coda.
Click on the search bar and start typing. (ie. another doc, a table name, etc.)
Improved links to other Coda docs.
Instead of seeing the literal, lengthy URL pasted into your doc, we’ve improved link previews to appear as clean headings. If your link is coming from another Coda doc, the link will display the doc and page name. If your link is coming from within the same Coda doc, the link will display as the page name and heading title. This feature beautifies your doc look and will also help to differentiate links and give more context to what’s on the page.
Start using improved links by:
Copy a URL link from another Coda doc.
Paste the link into your doc.
The link will automatically transform into a clean text.
Utilize these new features in your Coda account today and see how even the smallest details can make a visible difference.
Hi, I’m Ben, an engineer who has been working on search at Coda for the last few years.
One improvement also included in the launch is that hidden page titles and canvas content will no longer be visible in search results by default unless the searcher activates “show hidden pages” in the docs’ three-dot menu. While hidden pages should not be considered a security feature, we hope this change will help make hidden pages less discoverable in search and reduce scenarios of folks ending up somewhere they shouldn’t (a clear pain point we heard when we announced the beta).
With that said, table content on hidden pages will still be visible. We want to be more thoughtful in the solution here, as there are cases when you would want to see table content on a hidden page, e.g. there is a base table of all teams’ tasks on a hidden page, with views of that table on visible pages for each respective team, and someone wants to search for a specific task for their team.
On a broader note, I want to extend our biggest thanks to all of our beta testers for the improved in-doc search experience. Your feedback has been incredibly helpful, and our team read everything that came in, both from the public post and beta feedback form. This is an exciting milestone that builds upon the years of improvements that paved the way for this launch:
In 2023, we made it possible to search across “all docs” directly from in-doc search as well as launching a number of improvements to matching and ranking in global search.
In 2024, we added table content to global search in response to your feedback — a daunting engineering effort given the amount of table data available in Coda.
And now we’ve simplified search whether within a doc or globally. Today’s launch gives you more real estate to search-and-filter your results and rolls out refined matching-and-ranking abilities.
At the same time, we hear and understand the desire for greater options to manage content visibility and access. While it’s not the focus of this current improvement, here are some things that we’re currently working on and thinking about:
More search controls: Deeper customization and flexibility over search settings for app-like use cases, such as disabling the search bar.
Protecting tables from unintended edits: Table and column locking, which will allow you to prevent changes to a table’s configuration and values consistently from all entry points across a doc.
Ability to restrict which content different users have access to in a doc: Introducing new patterns including personal sync tables where different users can load different data into a doc, and over time more direct control on the visibility of different pages, rows, and columns within a doc.
This launch is the continuation of years of work at Coda, and as always, we welcome your feedback along the way. If you spot any issues, bugs, or have any ideas, feel free to use this form to send that feedback right to the product team.
What on earth have you done?! The new in-doc search has exposed highly confidential data across a number of our HR docs that I’ve had to lock down. It is highly irresponsible for you to launch a feature like this, with a “we’ll figure out the details” later regarding customizing data access and privacy features. I implore you to reverse this change immediately.
Hey there, we’d like to look into this further, since in-doc search respects underlying doc permissions. Would you mind emailing support@coda.io with this information, and let them know you came from the community?
And how exactly is that use case where hidden pages should be visible? that person has his team tasks visible on page for his team and its OK for search to work there.
Maybe I am missing something, but I really don’t see a single use case where HIDDEN pages should be visible to anyone who is not docMaker, because if docMaker decided they should be hidden he had his reasons. And its even worse if they are showing in search. I mean they are HIDDEN pages, this whole setup defeats their name
I mean its such a simple concept → hidden pages should stay hidden Unless docMaker decides they shouldn’t be hidden anymore and unhides them. Concept cant really be simpler but you guys are somehow constantly missing it.
Just ask anybody simple question : “Do you think that hidden pages should be visible and show in search?”
I know they are not “bulletproof” security feature, but they help a lot with day to day business workflows, and lets be honest 90% of end users of Coda docs wont go around and try to hack and use inspector or what not. But they will click on 3 dots (which they need any time they want to print something for example) and go unhide hidden pages, or click on them if they come up in search.
I really don’t believe we are discussing for YEARS now how should hidden pages behave… Kinda silly when you think about it
Thanks Brian. I’ve sent a note with screenshots to your support team. I gotta say though, I feel sick about these changes and the implications for systems my organization has come to rely on. I appreciate your prompt reply and hope your support team can help me figure out a solution asap.
Thanks for the improved search, but I am afraid there is a lot of work to be done. Upon clicking on a find result (finding text from within a table), it opens up a modal. On the top of the modal there is a link to the table on a hidden page. Clicking on the link opens the hidden page, even though hidden pages are not visible.
Searching for the word HiddenTable, it seems to separate this one word into two words, finding every instance of the word Hidden, no instance of HiddenTable and no instance of Table.
We have asked for years to give us an option to hide the search bar through a maker option - and what we get is an even more prominent search bar in every document we have ever made.
We have asked for a maker option to hide the table link in the top part of a modal. There have been some improvements as to where this link brings you, but we are back to square one of a user goes straight to the base table on a hidden page.
In my opinion, releasing this powerful new search comes the a responsibility of taking care of the things I just mentioned.
Even though I think search can be really useful, we makers should really have separate options to turn this on or off for makers, for editors or for viewers.
Happy to help! Coda users have had the ability to search across all docs since 2023, so nothing on that side has changed with this launch. There’s a good chance this is related to something else, but either way we’ll help sort it out.
Thank you. I will give you guys the benefit of doubt on this one and assume this launch was rushed because of some big customer’s pressure, as it’s definitely not wanted by the community. I really hope the ability to hide the search box follows in short order.
Does “Personal sync tables” mean what I think it means? My wish list for this feature:
Each doc user can log in to their own private third party service account in the sync table formula (currently only pack actions can use private accounts which always struck me as odd)
More importantly: collaboration will work as expected based on the id property of any given synced row: if row 123 is synced to your version of the table and mine, we can both see it and collaborate on it like a normal row, but it cannot (at all, not even with looking under the hood) be seen by a another user whose sync table formula doesn’t return it.
If yes, then this is truly the first time in a long while that a feature being worked by Coda actually advances the core underlying platform rather than just cosmetics - and for that you have all my encouragements
While you’re doing this engineering work, please spare a thought for some pack sync tables quality of life improvements:
Reliable way to push individual sync table row updates (including references) to Coda from the third party service : we have the webhooks infrastructure which could be leveraged for that.
Offer to Packs the ability to initiate row creation in a sync table (similar to how Coda’s own updated implementation of cross-doc does). The row could be in some local “temporary” state until the pack responds with the created row and it’s id.
You’ve done an excellent job, and I am sincerely grateful to you and everyone who contributed to this project. The new interface is more pleasant, and the search parameters are more flexible. All of this has been done at the highest level. However, I’d like to bring attention again to a long-standing issue that hasn’t been fully resolved.
Despite excluding hidden page titles from the search results, they are still vulnerable to discovery. Rows in tables on hidden pages still appear in search results by their titles. It’s enough to click on a search result, and in the opened record card, you can click on the “Row from…” link in the top left corner to access the hidden page. Furthermore, if the hidden page is a child of the entire page hierarchy, the user is shown the whole hierarchy, and they can navigate to any of the levels. The most resourceful users can simply add these pages to their bookmarks, which makes accessing them even easier.
Imagine this situation: A manager creates a financial table located in the same document as all the projects because it’s convenient. They use the “Hide” function and place the financial table on a hidden page. Each row in this table represents a month: “January,” “February,” “March,” “April,” and so on, containing important data they believe to be hidden. However, knowing the structure of the financial table, one can easily enter “January” into the search and land on the hidden page, which shouldn’t be accessible to outsiders. Or this can happen accidentally if there are rows with identical names in both the “private” and the public table. A user might intuitively enter a name they remember to open the correct record, but end up on an “interesting” record with the same name, but from the “private zone.”
As mentioned before, when users utilize the “Hide” function for pages, they expect those pages to be inaccessible to others. The very semantics of the word “Hide” suggests this. However, a number of scenarios render this function meaningless, and instead of being a helpful tool, the search becomes a source of problems. This causes disappointment because the developers haven’t fully addressed this issue, which is a real pain point for many doc creators.
Please please please let it be considerable as a security feature …. It is what we all are begging for years. Give us a chance to hide a backend, while creating a beautiful, reduced, filtered, save frontend for the user.
All the buggy crossdoc sync tables and pack options which are not working for all column types, not syncing comments etc are just complicated workarounds for something that is fundamentally there but can be discovered by a button and a searchbar… and there are veeery emotional debates on this topic for years in this community
so please add an option to remove the unhide button and the searchbar and we are all good.
If its still discoverable via devtools, then its not the biggest issue, since there is 0,01% of people named Paul (kudos!) who would even look for something…
Hi Ben, thank you for joining in the discussion, and for your work on the searching feature!
I have some feedback:
Previously, row results in the immediate search results would show either table name or page name (I don’t recall which, I think table name), and I believe an icon as well…now it’s showing up blank icon and just the text result (which is less useful than table name since I know what I’m searching for). I have to enter the new expanded search screen to see the underlying table.
It’s not obvious that typing enter will open the expanded search screen, but I suppose this will be a small learning process. I prefer to use the quick search results and am not a fan of the extra step to open the expanded results. In IDE’s like VSCode the full search results open immediately.
As others have said, hidden tables should be hidden if other things are hidden. Having things behave one way sometimes and another way other times is death by a thousand cuts, design-wise. + I’m seeing all sorts of rows I don’t want users seeing in results, including lots of duplication.
It appears that searching results in “parent” table results showing up before “child” table results (e.g. tables with relations to a parent). I just wanted to say this is great, I’m not sure if it’s coincidental based on page order or something, but the result is good. I guess it was this way previously as well, but glad to see this is still the case.
.