Hi mehak saeed , Ramesh Lokesh ,

Thank you for sharing this detailed feedback and real-world context. We understand how the current project-level export behavior can create bottlenecks—especially during active documentation cycles and time-sensitive releases. The points you raised around parallel exports, access isolation, and user-level ownership of export outputs are all valid and well articulated.

We can see how making exports user-scoped rather than project-scoped could significantly reduce coordination overhead, avoid accidental overwrites, and better align exports with individual access permissions.

We’ll review the technical feasibility of this change with our product and engineering teams, including its implications on security, performance, and overall export workflows. Once we have more clarity, we’ll share an update on possible next steps.

Thanks again for taking the time to outline the challenges and the impact so clearly—it’s very helpful for our evaluation.

This is a much-needed feature!

Sharing some context below:

In a typical documentation lifecycle, HTML exports aren’t a one-off activity, they happen continuously.

Early on, writers may export HTML to validate content in staging or offline environments. As work progresses, others may need to export the same or different sections to test changes, prepare customer deliverables, or verify what will actually ship. Then, when a release or patch is about to go live, multiple writers often need to export HTML at the same time to package updates for delivery.

Today, because exports are project-level, this becomes difficult very quickly. Writers have to wait for someone else’s export to finish, coordinate timing, and sometimes re-run exports because another user overwrote the output. In time-sensitive release scenarios, this slows everything down and adds unnecessary friction.

There’s also the access angle. Different writers have different permissions, but when exports are shared at the project level, it becomes unclear whether an exported HTML package truly reflects the access scope of the person who generated it. That’s risky for offline documentation, where being sure that you exported the right file matters.

If exports were user-specific, each writer could work independently, exporting what they need, when they need it, without blocking others, overwriting files, or coordinating outside of Document360 on whether the generated output is good to use.

Making HTML exports user-scoped would better match how teams actually work, especially during releases, and would remove a lot of avoidable coordination and stress from the process, and most importantly, SAVE TIME for everyone.