I have continued the chat about it in Coda chat support. But yes you are right, I am in category where max 3-5 coda makers ll be on team. My focus is ecommerce perosnal and ecommerce marketing for customers, so had hopes to integrate Shopify plugin, Coda AI, and replace some of the tools like (https://describely.ai/). Therefore 3k credits would not help, maybe a package to buy AI in bulk would also help where we can buy lets say 10k,50k,100k ai credits that stay in account until used. Although, I did truly hoped for at least 10k / doc maker ai credits. Thanks for the responses.
Love that use case - love to chat more about credit packages!
Hi Tim — yes, as you mentioned, changes will not take effect for existing subscriptions until November 6th. Your workspace admin(s) should receive an email with details on how to prepare for this change for your workspace. We’ve also updated our in-product reporting to provide more information about your Editors’ Total docs (docs they previously owned or were an admin of, or docs they’ve added pages to in the past 90 days) and AI usage; you can review all this and more in your workspace settings → Members tab (more on that here.)
Would a Maker or User be running this AI process?
Ya’ know - with the OpenAI Pack you are free to apply generative AI to any application without purchasing credits. If you use PaLM II (LLM) you can do all this initiall classification and summation for free.
I do think that editors can do a lot more than needed, but creating pages (or subpages) isn’t one of the features I would nix, personally. I would appreciate it, for example, if editors didn’t have the ability to establish new automations or new relationships, but COULD add subpages and use templates that have already been established.
Hi Reed — thanks for sharing your feedback. (I was initially also an AI skeptic, so I hear you. I hope you give Coda AI a try; we’d love to hear your feedback.) Our team has also been working hard recently to make it easier to search, organize, and navigate inside Coda — have you already tried out universal search and the QuickNav beta?
We also shared some updates today around sync pages (and sub-pages) that can be multi-homed across docs, so you don’t have to choose, and can have the same pages live across multiple docs.
Hey David saw your DM just now. Thanks
Fully agree, which is why I think its puzzling that the choice was made to paywall page creation - one of Coda’s most basic, familiar, and intuitive functions - rather than the higher end functions you mention. If their intent is to make sure that the doc architect must be a paid user than surely they should target the higher end rather than the low end?
What I’d want a member of my team to do most of all is the stuff that comes intuitively: writing out a process document and be proficient in using Coda basically as a word processor and a way to organize their thoughts. I don’t care if my team members can’t draw relationships between tables or wire up buttons. That stuff is best left to the doc maker to orchestrate anyways. So if we want to make sure the people constructing the docs are paying then why are we pay-walling basic organizational tools rather than power-user tools?
I would prefer they restrict setting up automations, configuring buttons, maybe even writing formulas before restricting page-making. Page-making fits very well under the “editor” moniker and is what my team would expect to be able to do.
I think Coda is a bargain, but obviously if I can avoid paying 20x the cost I am paying now then I will. So I’ll have to restructure our wiki doc to fit a narrower vision of what Coda can do. It’s just annoying more than anything.
In terms of changing who can create and manage docs, I see no issues with this change. By having one doc maker seat, a team can still set up the framework for editors to operate in. I feel like canvas columns could be the alternative.
Either way, if that change impacted <5%, why not “grandfather” those accounts?
Thank you Coda team!
I second this request!
I just wish that, since Coda went into that direction, also ability to unhide hidden pages was also moved to Doc Editors only as the rest, that would really make a lot of sense, since most hidden pages are “background” stuff normal users shouldn’t really see anyway.
I know its not meant to be security feature etc, but 95% of “normal” users wouldn’t definitely open developer tools and start sniffing around or use some programming techniques to dig up those hidden pages. On the other hand it would help so much for easier hiding pages with background logic/calculations etc. “end” users don’t need to see
edit: also I think access to version history should also be restricted to doc makers
One thing I miss about the two way sync is the ability to use CFL to modify the embedded Doc.
Do you guys have any plans to tackle that? Maybe by passing values in the url of the embedded?
It would be a game changer
Posted in another thread, will reshare here for everyone who comes with concerns about the editors/page downgrade.
Thanks for the thoughtful feedback here Marko! Just to confirm your intuition, with this update only Doc Makers will be able to hide and unhide pages.
Good feedback for us to consider on access to version history. We debated this too, but felt that it was important to keep Editor access to page history.
I thought that was already the case, oh wow. TIL.
Anyway, I think automations only stayed unlocked because editors could bring in templates (and templates could have automations). If the ability to add templates will be taken from editors, so will the automations. It really doesn’t make sense to keep them in the editor access level then.
Oh, amazing! I run my business as a solopreneur with Notion, and it got somewhat slow with my recent formulas and projects. I thought of jumping to Coda because of the seemingly more powerful formulas. However the docs limits where the deal breaker, it was such a let down. This new change sounds amazing! Thank you so much for considering us. I’ll get back to learning Coda for testing, and, if it performs well, migration.
Is it possible that the editors/pages feature will be added again?
Our company recently decided to use Coda instead of Notion and is in the process of migrating.
Due to this news, I think we need to reconsider whether we should use Coda.
Unfortunately, fortunately, we are still in a situation where payment is pending.
If there’s no chance of that feature returning, I think I’ll have to use Notion again.
We prefer a way for everyone to add pages. So everyone has to become a Doc Maker and then it would be more expensive than Notion.
Thank you for developing this pack.
However, it seems difficult for this pack to be an alternative.
The new page was created fine, but it was impossible to change the title of the created page.
To be honest I’m kind of relieved knowing pages can now only be managed by Doc Makers. They should generate profit or else we won’t have Coda anymore. Just be real, how can you run a doc with 100+ pages that’s accessed and edited by 10+ users real-time, only with $10 a month So yeah, I believe it’s not Coda being greedy.
What about the ability to “show hidden” pages, I think that is something that will be really welcome upgrade? Will that be moved to Doc Makers only? It makes total sense with the changes already made. That would also help a ton with many current workarounds so people don’t accidentally change some background stuff. Also there are always people who “like to see how things work” and then mess up stuff and since option to show hidden pages is there they start poking around xD.
Removing the option (which I guess is not that hard to do) and moving it to Doc Makers, as it should really be, would help a lot. Also would help with hiding some information that is not super sensitive, but still not all people should see, and still needed for doc to work.