Publish, republish, and unpublish a Helpdesk

Publish one coherent immutable Helpdesk version and use republish or unpublish deliberately Follow a safe workflow, verify the customer-facing result, and isolate common problems.

Publish one coherent immutable Helpdesk version and use republish or unpublish deliberately This guide keeps the work focused on Helpdesk publication and provides a repeatable path that a new Humind user can follow without changing unrelated configuration.

A Humind Helpdesk is a published projection of eligible public Knowledge. It has its own address, content selection, languages, appearance, navigation, support destination, metadata, and immutable publication versions. Editing the configuration or Knowledge does not change the public site until a new coherent version is published.

Before you begin

Access: Helpdesk write permission is required. Publication also depends on eligible public Knowledge.

  • Complete Helpdesk test for every active locale.
  • Confirm the content candidate, branding, links, support, and metadata.
  • Keep the current public version available while editing.

Work in the smallest owning area described below and keep the current customer-facing state available while you prepare the change. Before clicking any final action, confirm the active company, Agent, store, language, and market shown in Humind. A missing control can indicate read-only access or a capability that is not configured for this company. In that case, record the intended task and ask an administrator to review the exact permission or dependency. Do not bypass the boundary by sharing an account, copying data into another area, or promising a capability that the workspace does not expose.

Step-by-step workflow

  1. Confirm the scope and current state

    Review the published-version status and identify all unpublished draft changes before taking any public action.

    • Confirm the active company and Agent before editing.
    • Record the current state so the result can be compared after the change.
    • Stop if the screen or permission does not match the intended task.
  2. Prepare the change

    Test the complete candidate and resolve missing content, invalid links, or unsaved sections without unpublishing the existing site.

    • Use the smallest change that completes the customer task.
    • Keep authoritative information in its owning source.
    • Review labels, dates, language, and customer-visible wording before saving.
  3. Save and allow required processing to finish

    Choose Publish or Publish changes once to create a new immutable version, then record its version and public address.

    • Wait for the interface to confirm that the change is saved.
    • If synchronization, indexing, or publication is required, wait for its final state.
    • Reload the area and confirm the saved values persist.
  4. Test the complete customer journey

    Use Unpublish only when the whole Helpdesk must become inaccessible. For ordinary corrections, prepare and republish a corrected version instead.

    • Use a fresh session and a realistic customer scenario.
    • Check desktop and mobile when the result appears on a storefront.
    • Capture the exact failing step if the outcome differs from the expectation.

Important limits and operating notes

  • A successful save confirms persistence, not every downstream synchronization or public update.
  • Workspace permissions can hide an area or allow reading without allowing changes.
  • Do not copy volatile catalog, account, or customer facts into narrative content as a workaround.
  • Test only supported capabilities that are visible and configured for the current company.
  • Keep changes in Helpdesk publication separate from unrelated Agent, Knowledge, catalog, Inbox, or Helpdesk work.

Verify the result

  • The publish action reports the expected article count.
  • The public address serves the new version.
  • Collections, representative articles, search, links, and locales work.
  • Previous publication records remain intact and no Knowledge item was deleted.

Keep a short record of what you tested, which customer scenario you used, and what changed. This makes later troubleshooting more precise and helps another teammate reproduce the result without relying on memory.

Troubleshooting

Publish reports no eligible articles

Check article status, public visibility, active period, Helpdesk eligibility, language, and content selection. Keep the current version live while correcting the draft.

Saved changes are still absent publicly

Confirm a new version was actually published and that the public site reports it. A saved draft never mutates the active immutable snapshot.

Related guides

Was this article helpful?