This request was raised on behalf of Melody We’re using Document360 as the source of truth for help content that is exported and ingested into our proprietary software as context-sensitive in-app help. To support this, we rely on screen-level taxonomy (e.g., stable screen identifiers) to trace each article to the correct UI location. Problem: When exporting content as Project ZIP (Markdown/JSON), the export output does not include any article tag data. Tags appear to function only as search/filter facets inside Document360 and are not surfaced in exported Markdown or metadata payloads. Because of this, exported .md files cannot be programmatically mapped to specific product screens using tags alone. Impact: Without tags or structured metadata in exports, downstream systems cannot reliably: • associate an exported article to a specific product screen/context • build screen-scoped help bundles • maintain long-term traceability when titles/URLs/categories change This blocks a common integration path for embedding Document360 content in products. Current Workaround (not ideal) To preserve screen identifiers through export, we currently have to place those identifiers in the article Description field so they show up in the exported .md header. This workaround is problematic because: • the Description field is not classified as metadata by Document360 • the data is not stored in a structured way (harder to validate/enforce) • the Description field is intended for human context, not machine indexing • adding in-body content blocks is also not ideal, since those are treated as article content rather than metadata and can’t be governed consistently Request: Could you please enable one of the following (either would solve the issue): 1 Include tags in export metadata ◦ Export .md and/or JSON should include the article’s tags in a consistent machine-readable format. ◦ Example (Markdown front-matter or JSON field): ▪ tags: ["ctx:billing.invoices.create.modal", "aud:admin"] and/or 2 Support custom metadata fields that are exportable ◦ Allow admins to define custom metadata fields at the article level (e.g., context_key, audience, scope). ◦ Ensure these fields are included in Markdown and JSON exports. ◦ This would allow customers to implement structured integrations without relying on descriptions or content blocks. Why this matters: For teams embedding Document360 content into software UIs, tags/custom metadata are the correct place to store context identifiers. Exporting them would unlock robust integrations without forcing customers into fragile workarounds.
