Feature Request

When you add a callout first and then the text, it includes a callout title (like Tip!). But when you type the text and then format it as a callout, it doesn't have a title. As a result, our callouts look inconsistent because we have different ways of working. The behavior of callouts should be consistent, regardless of the sequence.

I could really use standard tech-docs-style section numbering, with H2 headings numbered 1, 2, 3, etc. and H3 headings numbered 1.1, 1.2., 1.3, 2.1, 2.2., 2.3, and so on. The numbers should be in the same font/size/weight as the heading itself, with periods as the separator between numbers. I personally would be happy with just a space separating the number and the heading. Others will no doubt prefer the number and the heading to be on different indent levels. Options probably need to exist whether to use numbering and when to stop. For example, numbering H2 and H3 but not numbering H4-H9. The numbering would appear in the TOC and the number itself should be something that can be used in internal cross-references, as in "See section 2.3" instead of "See section 2.3. A very long heading indeed" No terminal period in referenced numbers in case we're using them mid-sentence. Obviously, the number should auto-update as sections are added, deleted, promoted, demoted, and moved, and the references to them should auto-update as well. You know, the usual.

You can add conditional content in the editor. However, it is not possible to see in the editor which elements of an article are conditional content. This makes it impossible to grasp it at a later time or for team colleagues.

We want to allow readers to dynamically edit placeholder values within code snippets directly on the documentation UI. The modified values should be temporary and only visible to the reader during their session. Refreshing the page should reset the snippet to its default content. This will help users copy customized code without using external editors. The original article content must remain unchanged and not be editable by readers.

At this time, when we apply conditional content based on Reader groups, the team accounts are unable to view the content in the site. We would like the content to be visible regardless of the crieteria set. Thank you.

Private Notes are set up to allow All Users to view by default. This will inevitably cause a Private Note to be accidentally visible to users when a writer forgets to change the setting. The default for Private Notes should be all checkboxes cleared (none selected). This makes the Private Note invisible to all, except the authors in the Portal. There won't be any risk of users seeing a note they're not supposed to see.

Support for non-breaking spaces has already been implemented (Ctrl + Shift + Space) - thank you for that! We would also like to use non-breaking hyphens. German has a lot of compounds that are hyphenated. Thanks!

Currently we provide the conditional content option in the editor for various parameters such as Country, Date. It would be great if we could have the conditional content option for PDF export as well. Their use case is to ignore some article content while exporting the article as PDF.

We would like the option to configure individual column widths while maintaining an automatically fitted table layout on the page. Thank you.

Currently, there is no way to validate or test conditional content within articles. Conditional logic cannot be verified by admins or users unless they naturally fall within (or outside of) the defined criteria. This creates a gap where editors cannot confidently confirm whether conditional content is functioning as intended. For example: If the editor is not part of the target criteria, they cannot view the content to validate it If the editor is part of the criteria, they cannot confirm whether the content is truly conditional or simply visible to all users Requested Enhancement: Introduce functionality within preview mode (or a similar testing interface) that allows users to simulate different audience conditions. This should include: The ability to preview content as different roles, groups, or criteria sets A toggle or selector to switch between conditions (e.g., “View as X audience”) Clear indicators showing which conditional rules are being applied Business Impact: Ensures accuracy and reliability of conditional content before publishing Reduces risk of incorrect or unintended content visibility Improves efficiency by eliminating the need for workaround testing Enhances confidence in content delivery across different user groups Current Behavior: Conditional content cannot be tested unless the user naturally meets or does not meet the criteria Expected Behavior: Users can simulate and validate all conditional scenarios directly in preview mode