Replace or remove a Knowledge source safely

Retire obsolete Knowledge without leaving duplicate authority or breaking a customer journey Follow a safe workflow, verify the customer-facing result, and isolate common problems.

Retire obsolete Knowledge without leaving duplicate authority or breaking a customer journey This guide keeps the work focused on Knowledge maintenance and provides a repeatable path that a new Humind user can follow without changing unrelated configuration.

Knowledge is the source of business information that the Agent and Helpdesk can use. Articles, snippets, documents, webpages, and folders have different maintenance needs. Public visibility, publication status, active dates, translations, and Helpdesk eligibility determine where a source can appear, so content quality includes both writing and lifecycle settings.

Before you begin

Access: Knowledge write access is required. Helpdesk publication access is needed when the source appears on the public Helpdesk.

  • Identify every source that covers the topic.
  • Choose the approved replacement and content owner.
  • Record Agent and Helpdesk journeys that depend on the old item.

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

    Search by title, URL, distinctive phrases, and folder to find duplicates before editing the source you first noticed.

    • 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

    Prepare and review the replacement, preserving useful internal links and approved public translations without copying stale facts.

    • 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

    Publish or activate the replacement, allow indexing to finish, and test representative questions before deactivating or removing the old source.

    • 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

    If the item is public, review the Helpdesk candidate and publish one coherent new version so links and collections move together.

    • 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 Knowledge maintenance separate from unrelated Agent, Knowledge, catalog, Inbox, or Helpdesk work.

Verify the result

  • One authoritative active source remains.
  • Agent tests use the replacement.
  • Public internal links resolve in the new Helpdesk candidate.
  • The old source is no longer active or eligible, and unrelated Knowledge remains unchanged.

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

The Agent still cites the retired source

Confirm the old item is inactive, its chunks have been updated through the supported lifecycle, and no duplicate import contains the same text. Retest in a fresh conversation.

Removing the source creates a broken public link

Restore or redirect the customer journey by updating referring articles first, then publish the complete Helpdesk change atomically.

Related guides

Was this article helpful?