Feature Requests

Currently, Helpjuice treats each language as a separate silo, which makes managing multi-language knowledge bases time-consuming. For example, when moving an article in one language, the same article in other languages doesn’t move automatically. Similarly, creating a category in one language doesn’t create it across all other languages. The request is to link related translations so that certain actions (like moving or creating categories) can automatically apply to all versions of the same article/category — while still allowing manual control when needed. Why this matters: Teams managing multiple languages are spending excessive time repeating actions across each translation. This slows down content organization and makes it harder to maintain structure consistency between languages. The sync feature only applies to new content, so managing and restructuring existing content is very time consuming.

Instead of using the builtin translation features of Helpjuice, we would like to export articles from the primary language (en_US) and translate the exported files to various other languages with an external translation memory system, used by our inhouse translator. This allows us to leverage the existing corporate terminology database as well as previous translations. We would like to automate as much of the importing and exporting as possible. However, we are missing certain features in order to do this properly. 1) In the GUI we would like to see the option to flag content that has been modified after it has been translated. In other words: You export an article from English and translate it into German and French. You upload both translations and they reflect the original article's version at the time. In the meantime, a Techincal Writer makes changes to the English version and the translations are no longer accurate. In the current version of Helpjuice I don't see any clue or indicator that a translation is potentially out of date. In order to bypass this, our Technical Writer's need to manually keep track of changes in an Excel spreadsheet. Instead, we think Helpjuice could easily indiciate this situation in the GUI. 2) Ideally we would like to use the API to export all articles that have either not been translated at all and/or modified since they have been translated the last time. The workaround for the current version is to simply export all articles in the source language, split the json into individual html files and let the translation memory decide what needs to be translated. 3) With the current version of Helpjuice importing translated content via API is not really an option. We cannot realiably and in an automated way determine the article IDs of translated content that belongs to the source article. In other words: When exporting an article we would like to see an additional field that points to its exissting translation(s). With this information we should then be able to formulate either a "create" or "update" request with the appropriate ID to get our translation back into helpjuice.

Like google, make it so if someone has a typo or something in the search it will offer other search suggestions.

It would be great to have a reference for who reviewed an article (and approved it!) after it has been Published. Greyed out info is fine - but to go back and look at who signed off on it would be helpful.

It would be great if we could allow Collaborators to access some of the analytics data for their groups. I have dept heads who want access to the data, but I don't want to give them full admin access.

Currently, accordion titles are automatically treated as headings and included in the TOC. When headings are manually removed from the TOC, they reappear after editing and republishing, forcing repetitive manual cleanup. Managing large numbers of pages daily becomes inefficient due to the lack of a way to exclude certain accordions from the TOC. Suggested Improvement: Add an option in the editor for each accordion with a toggle or checkbox labeled “Appear in TOC?” (on/off). This setting would determine whether the accordion title is included in the TOC, allowing creators more control and eliminating repetitive manual edits. Impact: This change would save time for editors who frequently update bulk content.

It's cool that accordion titles can now be displayed in TOC, but as it automatically applies to all and there's no way to turn it off, it's very manual and time-consuming to delete the ones that you don't want displaying as headings in TOC every time you edit. We'd love at least the option to choose if an accordion title is a heading on not (toggle on/off), but ideally we'd like the ability to apply headings to the relevant accordion titles, and not to others.

Current, glossary goes across all languages, which makes it not useful if you have multiple languages for your KB. e.g. Our Japanese audience cannot use an English definition (and we have quite some terms that are not translated in all languages). Making the glossary, or specific terms linked to a language would make this useful for us.

Currently the MCP Server uses a single API key, meaning all actions are performed as the sysadmin account regardless of who the actual end user is. This creates both security and audit trail issues. Requested improvements: OAuth authentication – Allow end users to authenticate with their own Helpjuice credentials so actions are attributed to the correct user. Tool scopes/permissions – Add the ability to configure which tools are exposed to different users or integrations. For example, restrict access to sensitive operations like user management (Users ) and webhooks (Webhooks ) while allowing read-only article access. Why this matters: Proper audit trails showing who actually made changes Principle of least privilege – not every integration needs full admin access Enables safer deployment in multi-user environments (e.g., AI assistants with multiple end users) Possibility for custom tool clusters (eg. one MCP connection that only allows for searching the KB, another to only create new drafts, another that allows editing published articles and so on). This could revolutionize how we create, update and handle content in our KB.

When a Published article has a Draft revision it is not sorted under Draft & Unpublished section. Customer stated that this makes it hard for their team to review it.