Feature Request

Currently, if you want to add tags in bulk, you have to do it via the All articles section, while labels you can add via the index category pages. It would be easier and faster if there was an option to add tags directly via an index category page.

Currently, index category pages will show article descriptions if they're filled in, which is quite useful to provide users with a brief introduction of what an article contains. However, if the index category page has a nested index category as a subcategory, there is no possibility to add a description and for it to display it in the parent index category. It would be very useful to have the possibility to add descriptions to nested index categories and that these display in the parent index category like articles do. It would make the parent index category look more consistent and have the option to introduce a subcategory in index form.

Currently, category descriptions are available when a subcategory is configured as a Page type, allowing authors to provide contextual information for users. However, when a subcategory is configured as an Index type and contains only further subcategories, there is no option to add or display a description. The customer has requested the ability to add a custom overview/description for Index subcategories as well, even when they do not contain direct articles. This enhancement would provide users with helpful context before navigating into the nested subcategories, resulting in a more informative and consistent browsing experience.

When attempting to reposition a sub-category within a category by dragging, the Split View opens. The reposition fails, and a different category is shown.

My department is beginning to incorporate pages into our KB because they do a great job of providing a place for overview-type articles on content nested under the page. But I'm a little concerned that our end-users won't think to click the folder title itself and potentially miss critical high-level information needed to understand our software's more complicated features. For example, there currently isn't a way to visually distinguish pages from indexes or folders in the category manager. In Image A (see attachments), if I told you that 1 of the below category types was a page, 2 were indexes, and the rest were regular folders, how would you know which is which without clicking every category? I also, in particular, navigate the category manager primarily using the > arrow expanders / collapsers. There isn't really a reason behind why that's how I navigate other than "that's just how I do it". But if other users press the arrow to open up and browse content in the category manager like myself, then the page itself won't load and users won't be getting the context they need. Maybe it could help to include icons in the frontend (see Image B), the same ones used in the backend to help Doc360 users navigate their category manager. That way, users can see that the "Workflow Steps" functions like a folder with some kind of readable material attached to it. And once they figure out we're including key contextual information at the "folder-level", then they'll know to reference such information if they see the icon. I'm conscious that not all customers share our same preferences. I'm sure there will be other customers who prefer no icons, so perhaps this can be something you can easily toggle on/off. E.g. "Show category icons in category manager".

Currently, rearranging articles via drag-and-drop is unpredictable, resulting in unwanted actions when moving categories. Then, at times, the actions revert, causing further confusion as to where the categories actually live.

Content authors currently cannot attach structured metadata to standard Categories in Document360. Custom Fields are available on Articles and Page Categories, but standard Categories (folder-type navigation nodes) do not support this capability. This creates a gap for integrations that organize content at the category level and need to store audience or access metadata alongside the category itself, rather than deriving it from individual articles. Requested Solution: Custom Fields should be configurable and retrievable for standard Categories in the same way they are currently available for Articles and Page Categories. Specifically: Allow custom field definitions to target standard Categories as an entity type. Expose custom field values on standard Category API responses. Allow content authors to assign custom field values to standard Categories directly in the Document360 interface. Benefits: Content authors can define audience intent at the category level without tagging every article individually. External platforms can retrieve category-level audience metadata in a single API call rather than aggregating from article responses. Category-level and article-level audience metadata can coexist, giving teams flexibility in how they model content ownership. Use Cases: Multi-organization enterprise portals where content is structured by category and each category is owned by a specific organization or department; headless integrations that build navigation from category-level metadata rather than article-level aggregation.

Hello, I'd like to submit a feature request concerning label and tag filtering. I want to set several filters of the same category (e.g. labels) at once, that are connected with an „AND“-condition, so I only want those articles, which e.g. have both labels „finances“ AND „new". Right now the search filters with an „OR“-condition. Thank you!

Hello, I'd like to submit a feature request which allows to exclude certain articles with a specific label during label filtering in "All articles". E.g. I want to filter for articles with the label „finances“, but I don’t want to have articles with the label „finances“ which additionally have the label „not important“. Thank you!

I would like to request the ability to change or update the URLs or slugs of articles whenever I clone a category. Currently, whenever a category is cloned, the URLs of the cloned articles that category will inherit the URLs of the originals but appended with "-1" If it's possible to specify the prefix or suffix of the URL, i.e, "my-suffix-default-article-title" or "default-article-title-my-suffix" that would already be quite helpful.