Feature Request

When an article/category is cloned (also across workspaces), the respective revision history is lost! In some circumstances, this information would be interesting. There may be different approaches, for example, (a) option to clone with the complete history, (b) option to clone with at least the history comments, (c) include at least the info that it is a cloned article/category with a link to the original one (right now you cannot differentiate whether an article was cloned or created from scratch).

Please consider adding more details to the Article Revision or Article banner details to include a date the article was hidden to improve workflow efficiencies. The current options are not efficient, especially when through the maintenance of broken links. If an article that is hidden has a broken link, it still shows up on the report. If the article is extremely outdated,d there is no way to view this information other than using the Team Audit features when other team members have hidden the article from view. In this case, please navigate to Settings > Knowledge base portal > General > Team auditing > Now click on 'Events' filter > Then type Article visibility changed. Now you can export the events and confirm on which date the article was hidden. For smaller Knowledge teams, this is not an efficient workflow and is quite time-consuming. Perhaps a good place to add this visibility would be to the banner that is present on the Hidden article.

I would love to be able to generate a list of all the new articles published in a given time period, as well as the number of articles that were updated in the time period. Currently, you can only provide a list by publication date, but there's no way to determine whether it's a new or updated article, and any article that was updated again after the end of the time period is not included. That is to say, if I export a list of articles published in December 2022, what I get right now is only a list of what was published that month but not since then; if I have an article that I published in December but then updated in January 2023, it is not included in the December list. This would be very helpful for our reporting purposes, to allow us to know how many new and updated articles we're producing. Thanks for considering this request.

Document360’s current Revision History feature offers a strong foundation for managing article versions, especially with its code and rendered diff views. However, there’s still an opportunity to make the revision experience more intuitive, collaborative, and aligned with how modern documentation teams work. Here are a few suggestions that could elevate the feature to the next level: Make Differences Easier to Digest Current: Code diff and rendered views are available but not always easy to interpret—especially for non-technical contributors. a. Suggestion: Introduce a more intuitive, track-changes-style view directly in the rendered article. A visual, side-by-side WYSIWYG-style diff would help writers, reviewers, and stakeholders quickly grasp what's been added or removed without needing to parse Markdown. 2. Support Change Summaries and Inline Comments Current: Version updates happen silently, without context or collaborative feedback. a. Suggestion: Remove the character limit on inline comments. This would streamline feedback loops by reducing the need to break up thoughts into multiple, disjointed comments. It would also minimize visual clutter and make discussions easier to follow. b. Allow hyperlinks in comments, so contributors can reference relevant tickets, Slack threads, design docs, or style guides directly. This would enrich the context and keep everything connected within the editing experience. Improving the revision experience is about more than just visibility. It’s about empowering teams to work faster, collaborate more clearly, and trust their documentation processes. A few small enhancements here could have a big impact across writing, editing, and publishing flows.

Revisions of articles that are authored using the HTML WYSIWYG can be compared in either rendered view or code view. It seems that this is not possible with the Advanced WYSIWYG editor. There are a couple of use cases where this possibility would be really helpful, e.g. comparing changed link targets, markup cleanup, etc. PS: BTW, could you please sort the Category list in the Feature Request form alphabetically ;-)

The customer would like to have a log of changes that are made within the article versions. So that the readers would be able to know the changes that are made within the article

I need to know when and by whom an article was hidden

The "Document Difference Viewer" that displays when comparing article versions could use some improvements. Currently, I have to copy and paste each version into a third-party editor to properly compare versions. The red that is used to highlight changes does not have sufficient contrast for WCAG certification. For the "Code diff" section, when comparing pages made using the Markdown editor, it would be nice to display the text of each version in numbered lines (like in github, vscode, etc.) to make comparing between versions easier. Other UI improvements that could significantly improve the UX would be navigation that allows you to easily scroll between each difference ("Next difference ->", "<- previous difference", etc.), a search bar, and a toggle that allows you to scroll both versions at the same time (instead of independently) Thanks!

Unless I'm missing something, when an article is moved from New -> Published, any changes made over the course of the workflow, which can be substantial, permanently overwrite the original version when you click "Publish." I would like at least one snapshot of the article in its "New" state to return to after the initial publish. Ideally, we could get a snapshot per Save. If this means saves are manual, I'd accept that. (This is how Zendesk handles version control and it saved us a lot of pain).

It were great if you could filter or search for specific revision comments. Use case: To track the changes applied for a feature, you add some reference number (as used in your project tracking system, e.g. Jira) as a comment to the specific revision(s) of the affected article(s), e.g. a Jira ticket number. If you later need to see what exactly was changed for a particular issue in your project tracking system, you can search or filter the article(s) revision(s) based on that ticket number.