Hello @Johg_Ananda , we don’t have a specific post for this, but you can either DM me with your questions or post a new thread in Ask the Community.
1 Like
Yes, but how am I supposed to micromanage the seat-hopping? Most of my editors only need to occasionally create pages, but most of my editors need to do it.
I would rather Coda continued to charge for AI and left my editors alone.
Hi Mitchell, thanks for your feedback. I would love to hear more about why you think Coda works best for specific use cases, and not others for you. I will follow up via DM.
On Editors losing flexibility, I think Scott said it best in another reply: “But Coda still maintains the idea of an editor as an architect. Yes, no net-new pages can be added, but any pages that are existing can be architected. New tables made, relationships established, formulas written, buttons configured, automations set, etc. In my mind editors are still far more than editors. And editors are still free!”
We shared a bit more on this in this post, but we debated this change heavily internally (as you might guess), and it was important to us and the team that we maintain the collaborative feel of the product with any changes we make. This felt like the right compromise across the wide range of use cases we’ve seen people use Coda for.
As a non-profit ourselves, Coda is very generous with their non-profit discount and given the power and breadth of Coda that $18/month for each Doc maker is a steal.
Considering what we have to pay for the likes of Mailchimp and others, Coda feels like a massive bargain considering we run our all org using it.
I don’t really understand why you would expect it for free, there are literally millions of non-profits so it’s hardly like it’s niche.
4 Likes
Checking if anyone has noticed any new updates to the sync pages? Or are they behaving the same as they did when they weren’t split out from the rest of embeds?
Hi @khanh,
when I mentioned use case I meant specifically the pricing structure. To be fair, it’s a mischaracterization to call it a “very specific use case” since it works for me and many other small to large companies. I was really just thinking how Coda is either an insanely good bargain or more expensive than Notion if you have a case where everyone needs to be doc makers.
But that’s the thing: with this page-making restriction, that worst-case scenario becomes a little bit more possible. Putting page making on the paid seat does not align with my understanding of “Charge for makers, not collaborators”.
Makers are power users and wire up buttons and formulas and tables to make the app. Collaborators use the app. I would prefer that the app-constructing tools were restricted, not the basic building blocks that any layperson would expect to find in any application of this type. That to me aligns better with “Charge for makers, not collaborators”.
Restrict features that decisively separate makers from collaborators. As I mentioned in reply to Scott’s post, my preference would be that you take away button configs or formulas or table relationships from the editor role before you take way the ability to make a page.
I can completely understand that internally at Coda it would be a ludicrous thing for team members to lose these abilities, but at my small company it’s going to be probably a few years before anyone on my team feels comfortable enough to develop their own Coda “app” that suits them specifically. In that event, we would happily buy them a Maker seat.
We would prefer an approach where doc maker seats are properly representative of power users rather than throwing this curveball of restricting page making to the role, which targets the ground level of users rather than the top-end. Even if the end result is that the editor has less capabilities its worth it for the clear delineation between the types of user the two roles target.
Everything looks very good, except the page changes. This seems like it will divide the community, especially one that has a flow focused on Wikis.
It might be possible to get around the problem with pages by creating a duplication button with a field to change the page name, so editors would be able to create their pages and rename them independently.
It’s not as flexible as before, but it might get the job done. Here is a very basic example of what I mean.
Not to be the conspiratorial weirdo, but this page-limit change pushes most workflows into tables. Along with this, AI is being given away for free, almost as an incentive to use.
So basically, they seem to encourage users to use more AI and structured data, I imagine this has to do with training Coda’s own language models.
2 Likes
Hey James,
In summary, we’re introducing sync pages — formerly known as Coda full-page embeds. Sync pages let you have the content you need, everywhere at once, by allowing you add a page—and all it’s sub-pages—into multiple docs.
We just shared a community post with more details about sync pages, you can read it here.
1 Like
I look forward to incorporating these changes in my workflow!
For the two-way sync – does that allow for creation of records, or just changing records, in the second doc?
Thanks!
Hello @Chris_Herrmann ,
With today’s release, two-way sync tables do not allow adding or removing rows; we do hope to add that functionality in the near future. For the time being, you can continue to use action buttons to add/remove rows.
1 Like
Got it, thanks!
One more question, given the roadmap: will we see the ability to sync views (rather than full tables) and maintain relationships with related records? If not, will there be another method to accommodate this sort of work (syncing a partial, filtered table to another doc for security purposes, while maintaining all the relationships to other synced tables) that will be forthcoming?
I just don’t want to hack my way to a solution only to find that the work to get there might have been avoided if I just waited a week or a month.
Thanks!
Ok, I might be missing something but…
Synced Pages are nice addition, but requirement that you have to have access to source dock kinda limits its functionality drastically at the moment. I guess when we reach step 3 where we don’t need access to source it will become much more useful and I see some use cases where it will land nicely, still inability to reference that table in rest of the doc where its embedded limits its uses cases - but thats what cross-doc should do I guess
Cross doc (probably most painful Coda feature to work with), step in right direction BUT, I didn’t have much time to do some detailed testing and its late over here, nevertheless as far as I saw there is option for instant “pushing” of changes from “synced” doc to source one, but sync from source is still limited by old restrains (manually, daily, hourly)?
I mean that kinda vastly reduces functionality of this feature and also leaves A LOT of space for corrupting and overwriting data and ending up with bad results. I really don’t see how that can work in real world unless you are just using it for backup feature or you force people to constantly manually sync everything before any change which is impossible to actually do in practice 
I don’t want to sound overly negative, this new updates are definitely step into right direction, but somehow at the moment they feel like they are half way through 
Hopefully with future updates (and I hope those are bee soon 
) those features will get to the level we really need them to be!
1 Like
You can enable automated (fast) pushes back to the source if you’d like. Check out more here: Cross-doc | Coda Help Center under Enable two-way sync for Cross-doc
If I understand your question / case, this should work properly today if you have a filtered table synced in with cell lookup values pointing to a base table you sync in; this is the common case we see.
What doesn’t work today is when you have a table synced in with cell lookup values that you want to point to a filtered table you sync in. Fixing that latter case is on our roadmap, but not slated for immediate work.
To everyone affected by the editors/pages downgrade (@Timothy_Choi @Ariella_Messing @Mitchell_Wells @Christian_Conte1 et al) — there is a way to alleviate the blow.
There is still a way to add pages through Coda API, which will (as far as I know) remain functional for makers. It’s not a full replacement — there’s no way to delete or reorder these pages, and definitely it’s not as convenient as just adding them in the editor. Yet still it’s a valid way. The “add page” button can be implemented as a pack; the doc maker would then make a shared connection for it in their name. There’s plenty of generic Coda API packs already, but I went ahead and created a specialized one with hopefully a better UX and some specific design choices (e.g. only a doc owner can install it, and each installation is limited to only that doc) that’s also more secure than just allowing all API calls on the maker’s account:
[Pack] Add Page — As a doc owner, allow editors to add pages after 4.0
Before making it, I ran this by Coda and they were okay with it. To me this is but another proof that this change is not about paywalling but about making a right design change that in the long term will promote better practices. I’ve been around long enough to live through the whole 2.0 Pricing thing, and I can say for sure that the way they handled it really shows that Coda cares and listens.
1 Like
Hey Chris,
I got that, but sync from source to the cross-doc’ed table is still good old hourly/daily? That was my main complaint You can instant sync TO the source but sending data FROM the source is still on old “system” which is kinda strange decision (I guess it can be useful in some cases, but push sync in both directions would be huge improvement )
Ah, not yet unfortunately, but we plan to get there.
I’m afraid to say it’s not really two-way sync if one direction is delayed by one hour at least and the other is instant-ish.
So out of the two big announcements: two-way sync in Cross-Doc and Sync Pages , both are currently half-baked moves in the right direction, but definitely not the solutions we were waiting for.
Not wanting to rain on the parade, and you guys have all my support! But I can’t start using either feature, and need to hold out for more complete versions - hopefully before Christmas !
2 Likes
5 Likes
Also @Nad this isn’t totally true
Great, I can’t wait to see your deep dive tomorrow! (but I hope you don’t mean the solution is to add a ‘refresh synced table’ button )