Write and prepare an official letter¶

Use an official letter for a formal communication whose recipients, issuing context, approval, delivery and later filing need to be tracked. Preparing the letter brings those choices together. Saving a draft, submitting it, issuing it, sending it and confirming delivery are separate events.

Availability: This guide follows the intended three-step authoring journey in the inspected Final Screens. The backend supports draft creation, draft updates and submission. The current frontend still uses sample information and links that switch between demonstration states; it does not establish that your edits were saved or submitted. Connected use and environment delivery remain unverified. Several design details need correction, identified below. This guide does not certify the later delivery, workflow or filing journey.

Continue with Approve, issue and close an official letter for the saved-draft confirmation, approval decisions, issue, recall, archive and follow-up workflow. Delivery and the Records handoff explain their separate outcomes and recovery.

Before you start¶

Use the correct organization workspace and ask your administrator for official-letter authoring and viewing access. A name in the sign-off, a job title or inclusion in the recipient list does not grant that access. Authoring is not established as private to the person who created the draft. Coordinate with other correspondence staff before changing a shared draft.

Prepare the subject and body, the issuing position or organization unit, the intended recipients and their relevant contact details. Decide whether approval is required, which delivery methods may be used, whether follow-up work should start after issue, and how the letter should be filed. Have supporting files and reference details ready when they are needed. You can prepare a letter without attachments; later filing may require a trusted attachment.

The issuing position or unit must resolve to an effective authority holder in the organization's structure. Selecting an unrelated person as Prepared by does not override that requirement. The person operating Zerohive and the person represented by the issuing context can be different. If the correct authority cannot be resolved, ask the administrator responsible for the organization structure to correct it.

Step 1: Write the letter¶

1. Open Correspondence, then Official letters, and use Write official letter in the intended browse design.
2. In Write the letter, enter a clear Letter subject and, when useful, a Business reference, Workflow purpose and Classification.
3. Select the appropriate issuing Position or Organisation unit. Check any Prepared by, Issuing authority and Signing authority information against organizational policy.
4. Review Audience. The available labels distinguish People in this organisation from External recipients. This choice is descriptive context; it does not, by itself, prove restricted access or guarantee that every recipient is eligible for delivery.
5. Choose Plain text for an unformatted letter or Rich text for headings, emphasis, lists, quotes and links. Enter the Letter body and check its meaning and formatting.
6. Select Continue to move to recipients and routing.

The subject is required and can contain up to 256 characters. The body must contain meaningful text. The current request validation has a 10,000-word limit, but its count has not been verified against a visible rich-text editor counter. Business reference, workflow purpose and classification each allow up to 128 characters. Issuing and signing authority descriptions each allow up to 256 characters.

Rich text is cleaned before storage. Unsupported embedded images, tables, styles and other formatting may be removed; a body containing only removed or empty markup cannot be saved. Review the saved content before submission. Do not rely on pasted styling, a signature image or an embedded document becoming part of the letter automatically.

The official reference is assigned at issue. A business reference is your own contextual reference and does not replace that official identity. Some pre-issue design examples already show an official reference; those examples need correction. Organization stationery comes from the organization and branch information, rather than editable logo and contact fields in this form. See reading official letters for its currentness limits.

The validation companion currently makes issuing and signing authority descriptions look universally mandatory. The verified requirement is a resolvable issuing position or unit; the two descriptive authority fields are optional in the inspected contract. The form needs to explain that distinction consistently.

Step 2: Choose recipients and routing¶

In Recipients and routing, complete the recipient list, delivery choices, references, workflow settings and supporting files. Review these together: a delivery method without usable recipient details is not a complete delivery plan.

Address the right people¶

Use To for people or organizations being addressed and Cc for copy recipients. The current contract requires at least one recipient overall and supports these two roles; it does not establish a separate rule requiring at least one To recipient. Follow your organization's correspondence policy for who should receive the original or a copy.

Each entry needs a display name and either an internal person or organization-unit selection, or external delivery details. An internal entry cannot select both a person and a unit at the same time. Internal selections are checked against the current organization and must resolve to recipients. A name typed into the form alone is insufficient. External recipients need an email address, postal address or secure delivery detail; check that the detail is suitable for the method you intend to use.

Keep names and contact details accurate. The saved display name is supplied with the entry, so successful validation of an internal selection is not proof that every typed label or address is correct. A copy recipient is not a hidden recipient; there is no blind-copy role in this authoring contract.

The design currently combines Delivery instructions and external details in one box. General handling instructions and each recipient's delivery details are separate information. The connected form must capture them without losing which address belongs to whom. Do not assume that putting all addresses into a general note makes them usable for delivery.

Choose delivery methods¶

Select one or more Delivery methods from the returned choices: Email, Secure portal, Courier, Physical mail or Manual delivery. A Preferred delivery method, if chosen, must also be one of the selected methods. These choices describe what is allowed for the letter; selecting several methods does not send the letter through all of them.

Use Require delivery confirmation when confirmation is part of your process, and add handling instructions where needed. Instructions allow up to 512 characters. These saved settings do not prove that a provider is configured, that a delivery has been queued or that a recipient has received anything. Read the actual delivery evidence after issue and dispatch.

Link relevant references¶

Choose a Primary reference when the letter has a main parent or source reference. Add Related references for other relevant context. The verified choices are another official letter, a filed record, or an external reference. The design's suggestion to add a case or workflow is not currently supported by this reference contract.

An official-letter or record reference must resolve within the current organization. An external reference needs its actual business reference rather than a selected internal item. The letter cannot reference itself. Avoid duplicate links. Linked titles, reference numbers and statuses are saved context and may become older than the linked item's current state; a link does not transfer or complete that work.

Set approval, follow-up and filing¶

When Approval required is enabled, choose an Approval workflow. The Follow-up workflow serves a different purpose: if Start follow-up workflow after issue is enabled, a follow-up workflow must be selected. The offered choices come from published workflows. Their appearance in the selector does not prove that a process has started or that an approver has received work.

Review Cancel active workflows when recalled under your organization's policy. It records the intended handling for a later recall. It does not make recall instantaneous or undo work already completed. Issue, recall and downstream workflow recovery require their own verification.

Review the Records filing policy. The returned choices describe filing when requested, on issue, after successful dispatch, after delivery evidence, or for an HR query on issue. Selecting a policy does not itself create a record, choose an arbitrary register or guarantee filing success. Use the HR-query choice within the relevant personnel-case process; do not select it simply because it appears in the list. The design's fixed “official correspondence register” example is awaiting reconciliation with these actual choices. The Records handoff guide explains the selected file, manual policy override, pending request and registration versus filing.

The label After delivery is confirmed also needs care: the inspected behavior uses recorded delivery evidence as its trigger. An evidence entry is not necessarily confirmation that delivery succeeded. Always check the evidence outcome and the resulting Records link independently.

Add supporting files¶

Use Add attachments to prepare supporting documents, then wait for the upload process to finish. A filename displayed while a file is still being prepared is not proof that it has been attached to the saved letter. The save process accepts completed, verified uploads and can fail if an upload is invalid or unavailable.

The inspected authoring screens say nine supporting files, ten total including a letter bundle, and 25 MB per file. Those numbers and an automatically generated letter bundle are not established by the inspected letter contract or its shared upload capabilities. Follow the connected uploader's current rules and available storage; do not rely on those example limits. The complete shared upload and recovery guide remains unfinished.

When finished, select Continue to review the letter.

Step 3: Review and submit¶

Review the paper, recipients, delivery methods, approval requirement, follow-up workflow, filing choice, attachments and references. Check that the organization and sign-off are correct and that the body refers only to files actually included. An official reference should still be absent before issue. Review any changes made while moving between steps; a preview alone is not a saved result.

The intended final action is Submit letter. Submission moves a draft to awaiting approval when approval is required. When approval is not required, it moves directly to approved. Neither result means the letter has been issued, delivered or filed. An approval requirement starts a separate workflow handoff; its completion is not established by submitting successfully.

The inspected authoring companions do not show a complete saved-draft, successful submission or partial-failure recovery journey. Start again and Start from scratch are present, but their draft-discard and upload-cleanup behavior is unverified. Do not use them as a documented deletion or recovery mechanism. A dependable save-and-resume interaction is tracked as unfinished design and frontend work.

Save, resume and edit safely¶

The backend supports saving a complete draft without submitting it. A draft still needs its required subject, body, issuing context, recipients and delivery choices; saving is not a promise that an otherwise invalid partial form will be accepted. The intended authoring design mentions saving but does not yet provide a verified save button or confirmation sequence. The older frontend's Save draft demonstration link is not evidence of persistence.

Only a letter still in Draft can be edited through the draft update operation. Once it is awaiting approval, approved, issued, rejected, recalled or archived, this operation cannot revise its body or routing. In particular, a rejected letter does not automatically reopen for editing. Ask the responsible correspondence staff to follow the agreed correction process.

When revising a draft, recheck the complete recipient and reference lists: these are replaced by the saved selections. Existing attachments remain unless explicitly removed, and new completed uploads are added. Removing a file from a draft does not establish that its underlying stored object was deleted. The authoring contract does not establish automatic merging of simultaneous edits or a complete version history.

Recover when something goes wrong¶

A combined new-letter submission can save the draft before submission fails. A save can also succeed before the page's refreshed result fails to load. Support should reconcile the existing letter using its identity and operation time; an error screen alone does not establish that nothing happened. Use your approved support channel for details and avoid sending confidential letter content unnecessarily.

For reading the result, see Find and read official letters. For the broader purpose and responsibilities, see Correspondence. Use the linked lifecycle, delivery and Records guides for the subsequent actions. Their implementation limits, connected journeys and audience acceptance remain explicit; this draft does not certify those handoffs.