Understand and manage Support guidance¶

Use this guide to understand how global Support guidance is prepared, reviewed and made available to HiveAI. It describes the intended experience in the current Platform Console design and the rules implemented by the backend. The frontend is still in progress, so a complete clickable publishing journey is not yet established.

Know which library owns the document¶

Global Support knowledge explains the platform for its authorized readers. Organization-specific policies, machinery manuals and internal procedures belong in the organization's knowledge library.

Uploading a document into one library does not publish it into the other. Publishing Support knowledge also does not publish the public documentation website. Agree the owning team, purpose, intended audience and review responsibility before preparing a source.

Check your responsibility and access¶

An active platform Support staff member or platform administrator can read Support source information, inspect version history and submit an upload. Publication, archive and delete require platform administrator authority.

Tenant administrator access alone does not grant these platform responsibilities. An executive or manager title also does not grant publication authority. Ask the platform administrator to verify staff access when an action is unavailable; do not use another person's identity.

Prepare a suitable document¶

Prepare one nonempty document, no larger than 25 MiB. The accepted formats are plain text, Markdown, PDF, DOCX, PNG and JPEG. The file's actual format must match its extension and declared type.

Use a simple filename of at most 180 characters, without folders or control characters. Text must be valid UTF-8. PDFs are limited to 20 pages and must meet the supported structural restrictions; password protection, interactive actions, embedded files and unsupported structures can cause rejection. DOCX files containing macros, embedded objects or external relationships can also be rejected. Images must be a single frame, no more than 10,000 pixels in either dimension and no more than 40 million pixels in total.

File acceptance does not mean all text can be extracted or understood. Prefer clear, readable source material. Review image-derived text carefully; the current image-processing path uses English.

Describe the guidance clearly¶

Prepare the stable source name, title, a privacy-safe summary, language, intended audience and Support destination. Use lowercase letters, numbers and separating hyphens for the stable name. The title can contain up to 256 characters and the summary up to 1,024.

Keep the stable name when replacing guidance for the same source. A new version can change the title, summary, language, audience description and destination, but it cannot rename that source identity.

The audience description is not a confidentiality control. Keep secrets, tenant-specific material and private staff procedures out of global Support guidance. A destination describes where the guidance should lead; its presence alone does not prove that the corresponding page exists.

Find the intended review screen¶

The current design places Support knowledge under HiveAI in the Platform Console. The screen is titled Publish approved support guidance. It shows the source title and summary, document name and size, language, audience, Support destination and version status.

It also provides Open support library. The inspected screen does not establish the upload picker, publication confirmation, version-history navigation or archive/delete dialogs. When those controls are delivered, their steps must be verified before this guide gives a precise click sequence.

Read the displayed details and version together. If the uploader's name is unavailable, keep the version reference and ask the responsible team to verify who submitted it.

Submit and check a new version¶

The intended sequence is to submit one document with its metadata, retain the resulting version reference, and check processing status. A successful upload acknowledges receipt of that version. It does not make the content searchable.

The service preserves the submitted document and metadata as that version's evidence. It rejects an additional active version containing the same content and metadata. Changing the metadata can create a distinct version even when the file bytes are unchanged.

If a connection fails, check whether the original upload was accepted before starting another. The integration supports replay of the exact original request; changing its content while reusing the same operation is a conflict. The frontend's recovery interaction still needs verification.

Understand processing and publication states¶

The old published version remains the source's current version while a replacement is pending. After promotion, search activation follows separately. That later step can fail or be delayed, so uninterrupted access to the previous answer is not guaranteed throughout the switch.

Review before requesting publication¶

Check the content, source identity, language, audience description and destination. Confirm the version you intend to promote and whether another publication is already pending. Only a verified Ready version can be selected.

The platform administrator requests publication against the current publication state. If another publication has changed it, refresh the source and review again. Confirm that the request still names the version you reviewed.

Request acceptance is not completion. Follow the same source and version until the publication result and actual Support answer availability have been checked. If this is the first publication, there is no previous published version to fall back to.

Replace or restore guidance¶

To update a live source, upload a replacement under the same stable source name, inspect its processing result and request publication of that exact Ready version. Staging a replacement does not immediately replace the live title, language, destination or document.

To restore content from a superseded version, upload that content as a new version and review it again. The current workflow does not reactivate the old version directly.

After processing has failed, a new upload can use the same content and details. Repeating the original upload request only retrieves its existing result. Ask the responsible team to resolve the cause before uploading again.

Archive or delete a source¶

A platform administrator can archive a published source or delete a published or archived source. A draft cannot be deleted through this source lifecycle. Archived and deleted sources cannot receive new versions through the current workflow.

Treat these actions as withdrawal from Support use. They retain history and do not establish physical erasure of documents or backups. No restore action for an archived or deleted source is established by the inspected workflow.

Check the source state as well as the version's historical publication label. An old version can remain identified as the previously current version after the source has been withdrawn.

Recover from delays and failures¶

1. Keep the safe source and version references, the visible state and the approximate time.
2. Check whether the original upload or publication already exists.
3. Distinguish processing failure from publication preparation failure and from a published source that is not yet searchable.
4. Ask the responsible team to investigate the existing attempt before submitting another.
5. Confirm current access and the exact version before resuming.

A pending activation is not cleared merely by submitting a new publication request. The current interface does not establish a self-service cancel or retry control. The engineering and operations reference covers the underlying evidence needed to investigate it.

If stored content cannot be verified or retrieved, use the trusted original document and the approved recovery process. Do not edit source history or assume a timeout means nothing happened.

Check answers and report stale guidance¶

After publication, check a representative Support question and its cited source. Confirm that the answer refers to the intended current guidance. A publication label, upload receipt or example screenshot is insufficient evidence that the answer path is working.

Users and managers should report incorrect guidance with a safe reference and a concise description of the mismatch. Avoid including passwords, private records or full document contents. Executives should assign guidance owners and review dates rather than infer completeness from the number of published documents.

Example: replace access-recovery instructions¶

Support prepares revised access-recovery guidance under the existing source name. The upload creates a new version and processing marks it Ready. A platform administrator reviews that version and requests publication.

While activation is pending, the existing version remains the source's current guidance. After promotion, the team checks that the new guidance is actually returned and cited. If search activation is delayed, the team keeps the original publication reference and investigates; it does not announce completion solely because the source says Published.