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.

While editing and formatting content in Document360, maintaining visual consistency across headings, paragraphs, and callouts is crucial for readability and professionalism. Currently, formatting must be manually replicated, which is inefficient and error-prone. There is no Paint Format (format painter) functionality in the editor. As a result: Users must manually match font, size, color, and spacing. It increases editing time, especially for long or complex documents. It introduces a higher risk of formatting inconsistencies. Proposed Solution Add a Paint Format button to the editor toolbar. This would: Allow users to copy formatting from one text block and apply it to another. Improve editing speed and overall efficiency. Ensure consistent styling across documentation. Impact This feature would benefit: Technical writers maintaining large documentation libraries. Editors applying global style changes. Any user aiming for visual consistency without repetitive manual work.

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.

When tables are bugger than the fold and you scroll down, you cn't see the table headers. Allow me to decide, for each table, whether to lock the table header.

The icons for expanding an accordion (chevron up) and collapsing it (chevron down) are not intuitive and should better be the other way round. I expect up to collapse and down to expand. Plus for expand and minus for collapse would also be good.

Raising the request on behalf of the customer It is expected that the all the folders in the Drive appear collapsed when we initially access the 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.

When I search for content in Drive, I can easily see the results but have no idea WHERE the files are located in my Drive folders.

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.