HTML Offline Export with Category-Level Structure
under review
D
Dusk blue Perch
When exporting multiple categories in HTML offline documentation, all articles are merged into a single docs folder with shared assets and one index.html. The category-level structure is not preserved.
Problem / Use case
We manage ~26 modules where each category or subcategory maps to a module in our help center repository. The exported HTML is not used as-is and needs to be pushed into a structured repo. Since the export flattens everything, each writer has to export categories individually and manually merge them, which leads to repeated effort and multiple deployments.
Expected behavior
Allow exporting multiple categories such that each category is preserved as a separate folder (with its own docs, assets, and index.html) instead of merging everything into a single structure. This should align better with repository-based workflows and reduce manual effort.
Log In
D
D360 Product Management
marked this post as
under review
K
Kavya
Hi Dusk blue Perch,
Thank you for sharing this detailed use case and the additional context from your team—this clearly highlights the operational impact.
Currently, the HTML offline export is designed to generate a unified documentation package, where all selected categories are merged into a single docs structure with shared assets and one index.html. This is the expected behavior today.
We understand your requirement to:
-Preserve category-level structure as independent folders
-Align exports with repository-based workflows and CI/CD pipelines
-Avoid manual restructuring and repeated effort across teams
Given the strong use case (modular documentation, multiple contributors, pipeline integration), we’ll take this as an improvement request.
We’ll evaluate the feasibility of:
-Supporting multi-category export with preserved folder hierarchy
-Generating independent bundles per category/module
-Ensuring compatibility with automation and deployment workflows
This will be reviewed based on priority, implementation scope, and customer traction.
We’ll share updates as this gets evaluated further.
J
Jambalaya Mouse
We rely on a specific structure for our pipelines to work smoothly. Since the export does not follow that, we end up making manual adjustments before anything can be used. It breaks the flow.
Q
Quail Cat
We cannot directly use the exported docs in our CI/CD workflows. We always have to clean up and reorganize files first, which defeats the purpose of automation.
S
Safflower Kangaroo
Our updates usually go out in smaller chunks. With everything bundled together in one big export, it is hard to pick and update just one part without touching the rest. That creates unnecessary work during releases.
R
Rare Lobster
We often need to share only relevant documentation with customers based on what they are using. With the current export, we have to manually filter out everything else, which takes time and can lead to mistakes.
F
Fuzzy Narwhal
We keep our content organized in separate folders internally. When we export, everything comes out in one place, and we have to spend time restructuring it again. It adds an extra step every single time.
G
Granite Crayfish
Different people on our team handle different parts of the documentation. Right now, everyone just pulls what they need individually to avoid overlap. It works, but it is not efficient at all.