When you share a doc, you’re extending an invitation for collaboration. And with the launch of today’s new features, you and your team now have more options for how you work together.
Ready for action!
Rather than suggesting through comment threads, you can actively edit (and keep a record of those edits) by using the suggest changes setting. Select it within the comment bubble icon next to your avatar and any changes will generate a thread where others can either approve, reject, or leave a comment. This makes it easier for all team members to get more closely involved, and if you have questions, you have a quick way to start a thread.
So…what happened?
If you need more context on what changed, the updated version history automatically highlights any edits with red or green, to show who did what.
Just browsing!
If you don’t want to make any changes but have thoughts about the content, use our new commenting features to ask a question, leave feedback, or react with your favorite emoji.
With these new features, it’s easy for your whole team to get involved—without getting in each other’s way. And when everyone is invited, your collaboration hub feels more like a home.
This just struck me. The biggest issue I have with my clients is tracking requirements, changes to those requirements, reasons those requirements changed, the status of that requirement, and assigning of an open issue for that requirement to a specific person or group.
Is this our answer?
Does this also work in cells of a table layout, or just pure text?
Small feature request: make it possible to hide Automator Bot actions in the version history. When you have an automator action that runs hourly, it makes it hard to find edits. Ideally, it would be possible to hide or only show a specific user.
THANK YOU! Haven’t tested this yet, but assuming it works well, I can finally drop Google Docs for my team and work fully in Coda! This was the last holdout feature!
Suggest changes edits right now are only limited to text in the canvas and canvas columns. However we have tried our best to enable as many features on the canvas as possible, so make sure to try various types of formatting.
Version history should let you see when every type of edit was made including in tables, cells, and the canvas.
In an ideal world Coda would also expose the same functionality via a formula, e.g. diff(beforeValue, AfterValue) outputs formatted text with additions in green underlined and deletions in red strikethrough. Any chance of that, Codans?
Can I just say every time I receive one of these emails I find myself cheering at my desk about whatever cool new update this team has made. Thanks for making and continually improving an amazing product!!
I’m a lawyer, and one of the (many) handy use cases we have found for Coda is as a sort of ‘content management system’ for complex legal documents that need to be tightly controlled for the benefit of a wide range of stakeholders.
Take the example of customer-facing terms and conditions and privacy policies in the banking sector, where a single policy or set of Ts&Cs could be relevant to many different products and departments across the bank. Coda makes it much easier to have a single shared repository where we can document why each clause is written the way it is (kind of like documentation for source code), how it has evolved over time (kind of like version control for source code), who needs to be consulted before a particular clause is changed, and what issues have come up since the last version was published that might need to be addressed in the next update. To aid this type of tracking, it’s best to store the clause text in table rows rather than on the page, since there’s lots of data we want to associate with each version of each clause .
Against that background, you can imagine how useful if would be if we could easily diff two versions of a clause via a formula. While it would now be technically possible to do some kind of diff with the “version history” functionality, it’s not really the UX we need, because the user would need to leave the specific UI we have built for browsing the clause content and associated data, and instead go into the version history viewer, and hunt through the rather messy looking edit history. It would be much better if we could compare text ‘in situ’ by generating a diff within a formula column.
My marketing team were the last hold-out on our ‘everything in Coda’ effort, because they insisted they needed to collaborate on copy edits and need to see and cross-approve tony changes to wording.
This update just solved that problem in one clean sweep. well-done Codans !
Version history will track all changes made on a doc starting from when the doc was created. This works for all types of edits including those that are “suggested” as well as normal canvas changes.
Thanks for all the feedback, @Tim_Sherman1! That’s a very interesting use case, and great to hear that Coda has been helpful for content management of these types of documents.
At the moment, the specific functionality you mention is not on the roadmap, but we’ll keep you and the Community updated on any adjacent features that can help with your broader goals.
When I want to make a new update to the Action Item (Clause wording) I click on the archive button. The result is that the original content of the action update column is copied to an archive column. Then the original column is made blank, and the current date entered.
One then always have the history easily visible, including the date on which it was changed.
Alternatives:
Create a new row, and use an indicator to distinguish between various entries.
Have an additional column(s) with the person that made the change, the authoriser, the motivation for the change, etc.
This is a step in the right direction! but still looking for the “revert page back to this state” button or “revert this particular change”. Having to copy your entire doc to undo a single copy edit is insane.
Even if revert button was available for the entire doc rather than having to deal with copies, that would at least be a little more tolerable.
I would be great to have the possibility (just like in MS Word) to have a view that shows me how the document looks like when all the suggestion were accepted. Right now there is “only” the view 1) how the document looks before the suggestions and 2) how to document looks when the suggestions are not accepted yet (including strikethrough words that were deleted and green words that were added).
As far as I can se only users with “can edit” access are allowed to make suggest changes. Shouldn’t that be accessible altso to the users with “can comment” access? Don’t understand this limit, as this is a great function for everybody to make changes, so the editors can approve.
