Feature Request

The current implementation is using the heading name as the # locator. Let this implementation be intact. But when the user is going to use any heading as a link, we need to start maintaining a mapping between that link and its # locator. From that point on, we need not change the # locator based on the heading name change(even if the heading is deleted). Please note that in the link pop up modal, we are only showing the heading name in the drop down, hence the UI will also stay unaffected. This solution will also not hinder our Block level styling customization. If we agree on this requirement, I will bring this to our requirement review where we can discuss the other impact areas for this change like migration and how we can accommodate this request with the "Link to paragraph of other articles" feature.

Instead of having to go through existing table and changing them to be this setting, why not make this the default so that PDFs don't get screwed up.

Currently, when the table width exceeds the screen width, the scroll bar is located at the bottom of the table. This design can be inconvenient for users, as they need to scroll all the way down to access the scroll bar and then scroll back up to view the content. On behalf of the customer, I would like to raise the following enhancement requests to improve usability: Persistent Scroll Bar Position: The scroll bar should always remain visible at the top layer of the content. This ensures users can easily access the scroll bar without needing to scroll down to the bottom of the table. The position of the scroll bar should make it accessible at all times without disrupting the content-viewing experience. Conditional Display of Scroll Bar The scroll bar should only appear when the table exceeds the screen width, similar to how the "Powered by Document360" logo is displayed above the vertical scroll in the Category Manager.

I asked to hide the language drop-down because we only have 1 language. I got a reply that when multiple workspaces are present, both the version and language dropdowns appear. This feature request is to have the possibility to hide the language drop-down, especially when there is only 1 language. The fact that there is a drop-down may inspire our customers to ask for documentation in more languages and we only want to maintain our documentation in 1 language, English.

The release for the new version says "To simplify the experience, the Insert option has been removed from the right floating menu, as all insert actions are now easily accessible through the Quick Insert menu." But they're not, really. After selecting text my options for inserting are reduced. I can't select and add a link or a glossary term, for example. It's also much easier to have the Format/Insert/Content reuse menu continually visible on the right, so you can just select and click; instead of having to open the tiny popup menu.

Currently Analytics will show you the things you have linked 'to' in an article. It does not show you what, or how many 'other' articles are pointing 'to the article you are working on'. If you want to delete the article you are working on, and it has links pointing to it from 10 other articles, then you will get 10 broken links and a bad user experience.

I may have posted this a while back but this is one of my biggest frustrations. I need to edit an Article to view\copy parts of its HTML and then Undo the fork. Administrators should have an option to View HTML without having to edit anything.

It would be valuable to have glossary terms automatically sorted in alphabetical order in Document360. Currently, terms appear in the order they were added, which can make navigation difficult, especially in large glossaries. Suggested Implementation: Option to enable auto-sorting A–Z (and Z–A) in the glossary settings. Alternatively, a "Sort Alphabetically" button to apply sorting manually when needed. Use Cases: Ensuring consistency and easy scanning of terms Helping writers maintain order without manually rearranging entries

Some contributors are lazy about image naming, and will simply add a bunch of images named "image" , one at a time, to an article as they work. This results in many image files in drive with names like image(78).png, image(102).png, and so on. This of course is bad practice and makes it difficult for editors and authors to maintain topics. For example, a common and frequent use case is the need to _update_ an image with a newer screenshot as product interfaces evolve. In this use case, you are looking at the article in the editor, seeing the image name, and then opening Drive in a separate browser tab and searching for that image name so that you can use "Replace" to update that image with a newer screenshot/diagram/etc. Problem is, when contributors are lazy with their image file naming as they author, and you end up with vague file names like image(35).png, an editor might want to _rename_ that image file to be more descriptive of its content, and to follow style guidelines and naming conventions. Except Doc360 does not allow us to rename existing images. Why not? You know the image dependencies. Why not allow us to rename an existing image, and Doc360 can follow the dependencies and update the image name portion of the imageURL to match, in all dependent articles? The [Title](imageURL) syntax is plain text and should be simple to update automatically when someone renames the corresponding image over in Drive.

Currently, when multiple Knowledge Base (KB) articles contain similar content, the search results do not always display the most relevant or preferred articles at the top. This can lead to difficulty in finding the most accurate or frequently referenced content. We request the ability to manually or dynamically control the order in which articles appear in search results.