Troubleshoot changes that do not appear in the Helpdesk
Trace a missing Helpdesk change through Knowledge eligibility, selection, language, saving, and publication Follow a safe workflow, verify the customer-facing result, and isolate common problems.
Trace a missing Helpdesk change through Knowledge eligibility, selection, language, saving, and publication This guide keeps the work focused on Helpdesk publication troubleshooting and provides a repeatable path that a new Humind user can follow without changing unrelated configuration.
When customer-facing behavior is missing or stale, isolate the layer that owns it: source content, visibility, indexing, Agent configuration, deployment, permissions, or publication. Checking one layer at a time produces a useful diagnosis and avoids broad changes that hide the original cause.
Before you begin
Access: Knowledge and Helpdesk read access is required. Correcting and publishing needs write permission.
- Record the exact public URL, locale, expected change, and current published version.
- Confirm the Knowledge item and Helpdesk belong to the same company.
- Do not unpublish the current site while diagnosing a draft difference.
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
Confirm the scope and current state
Open the Knowledge item and check article type, published status, public visibility, active period, Helpdesk eligibility, language, and parent folder.
- 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.
Prepare the change
Open Helpdesk content and confirm all-public or selected mode includes the item and any expected descendants.
- 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.
Save and allow required processing to finish
Save every modified Helpdesk section and use Test to determine whether the candidate contains the change while the live site remains on its older version.
- 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.
Test the complete customer journey
When the candidate is coherent, publish one new version and verify the public version, collection, article, search result, and internal links.
- 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 troubleshooting separate from unrelated Agent, Knowledge, catalog, Inbox, or Helpdesk work.
Verify the result
- The exact failing eligibility or selection condition is identified.
- The Helpdesk candidate contains the corrected item.
- One new publication becomes active without an outage.
- The public locale and article report the new version and expected content.
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 candidate is correct but the public site is old
Publish the saved candidate and verify the version reported by the public site. Clear browser state only after proving the server version, because caching is not the only possible cause.
The article appears in one language only
Review article translations, enabled Helpdesk locales, localized folder names, and the requested locale. Do not activate an incomplete language merely to expose source-language content.