Feature Requests

We’d like to generate read-only API keys. Right now, all API keys have Super Admin–level permissions, which makes it unsafe to share with team members or third-party tools who only need viewing access.

When republishing an article after making edits, it would be helpful to include an internal change log that allows authors and collaborators to document what was changed and why. Users should be able to change the authors and collaborators of each article to ensure that the correct person receives notifications related to edits and updates. For example: “Updated screenshot for accuracy” “Added new section related to XYZ feature (Jira #1234)” This feature would help writers, editors, and collaborators easily understand the purpose of each revision when viewing version history, especially when reverting to a previous version.

Here’s the user story: I need the ability to assign 1 department specific administrator, collaborator, and draft writer to a category. In this example I want to assign 1 person in Marketing as an administrator, another person in Marketing as a draft writer, and another person in Marketing as Collaborator. But I only want them to have that particular job duty (admin, collaborator, draft writer) for that category – in this example Marketing. But I also need those same people to have viewer capabilities to the entire library

The new automatic creation of versions when any change is made to a previously published article is now making it difficult to identify where/how information has been updated. Can we please make the "Compare with Current Revision" button on the Revision History screen available when a different article version is selected?

Hello, similar to the "Improve Groups Management" request, I'd like to be able to create a group, that inside has other groups. This would work fantastic as many teams have users that are shared among areas, for example engineers and architects are distinct groups but can see the same content, so instead of having to add each group to a new category, I can just create a group say "Arch+Eng" and then inside have the two groups of Architects and Engineers, and if I have to atomize the information, say a section relevant for engineers and a section relevant for architects, I don't have to keep adding each and every group to each and every category they should belong to.

When replacing an image in the files manager, you would need to then replace it manually in the articles, this increases the workload x10000. This tool would be much useful if it replaces the image everywhere.

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.

Be able to define collaborators or admins as having permissions to publish in certain groups/categories only. That way they can freely edit and publish in their selected category and not be able to do so anywhere else on the knowledgebase.

Once we submit an article for review, we can't remove the review state unless we publish it. This isn't ideal in scenarios where the article was disapproved and we just want to get it out of review and submit it again when it's adjusted. In these cases, we have to publish the article and unpublish it to remove the review state. Once the reviewer disapproves the article and the author makes the changes, he can't resubmit it for review. How does the reviewer know they updated it and that they need to review it again? Related to those two points, users without the "unlock publish" ability cannot get articles outside of the review state and cannot re-submit them for review. The only approach right now is to add a comment in the article to notify the reviewer that he needs to check it again. Review comments aren't saved in the editor. We should have a log of the review rounds with the corresponding comments.