Staging draft Work in progress · For review; coverage and acceptance incomplete

Deliver an official letter and record evidence

Use delivery to send an issued letter through an allowed method, then record what happened to the selected attempt. A letter's issue, delivery, acknowledgment and filing are separate events. Keeping those distinctions clear helps correspondence teams follow up without sending unnecessary copies or treating an incomplete delivery as finished.

Availability: This draft follows the inspected WorkOS Final Screens for Queue delivery and Record delivery. The backend implements delivery requests, email attempts and evidence recording; the frontend action pages still use sample navigation and fields. Connected use, provider readiness and environment delivery have not been verified. These are the intended steps, with the current differences called out below.

Start with finding and reading a letter. For approval, issue, recall and archive, use the letter lifecycle guide.

Before you start

You need permission to manage official letters and separate permission to read the letter afterward. A role title or being named as a recipient does not by itself establish those permissions. The inspected management actions do not require you to be the original author, so administrators should assign management access with care.

To queue delivery, the letter must be Issued. Check its subject, official reference, recipients, attachments and saved delivery methods. You choose one allowed method for each attempt; choosing the preferred method does not queue every other method. Draft, Approved, Rejected, Recalled and Archived letters cannot start a new delivery attempt through this action.

To record evidence, an attempt must already exist. Select the attempt for the right letter and delivery method. Evidence can still be recorded for an existing attempt after recall or archive; those stages do not erase delivery history or prove that work already under way has stopped.

Understand the available methods

Method What the current implementation does
Email Attempts a separate email to each saved recipient with an email address, subject to the recipient tracking and retry limits below.
Secure portal Records work as in progress for manual or external handling. Selecting it does not currently transfer the letter through a portal.
Courier or physical mail Records work as in progress. Your correspondence or registry team must arrange the actual transport.
Manual Records work requiring handling outside the automated email path.

The backend's allowed-method catalog is broader than the single selected value visible in the inspected dialog. A method must also be in this letter's saved delivery plan. Its presence in a choice list does not establish a configured carrier or provider.

For email, the current sender uses the saved subject and body. It does not automatically include the letter's attached files, create a letterhead PDF, or send the document shown in the letter preview as an attachment. The saved delivery instructions and requirement for confirmation do not cause the sender to attach files or obtain an acknowledgment. Resolve any requirement to deliver an exact signed document or supporting package before relying on this route.

Recipients without an email address are omitted from the email attempt. For example, if a letter names three recipients and only two have email addresses, a successful email result can cover those two while the third still needs another method. The saved To/Cc labels are not reproduced as a combined email's address headers: each selected address receives an individual message. Duplicate addresses can also make the reported totals misleading; ask the correspondence team to reconcile them before treating the attempt as complete.

Queue delivery

  1. Open the issued letter from Correspondence → Official letters and review its contents and delivery plan.
  2. In Letter actions, choose Queue delivery.
  3. In Queue delivery for this letter?, choose Delivery channel from the methods saved for the letter.
  4. Enter a Queue remark explaining the handoff. Keep it short. The design currently labels this optional, but the API requires it; the documented input and stored length limits also need alignment. A remark within 512 characters avoids the known storage-length mismatch.
  5. Choose Keep viewing to return without queuing, or Queue delivery to confirm.
  6. Refresh the letter's operations and locate the new attempt by method and attempt number. Check its progress before taking another action.

Confirmation means a delivery request was accepted and an attempt was created. It does not mean the provider has accepted the email, the courier has collected it, or the recipient has received it. Email work proceeds in the background; other methods need the manual or external handoff described above.

Each new queue action creates another attempt, including another attempt using the same method. It is not a retry button restricted to recipients who failed. Coordinate with the delivery owner before queuing again, especially after a timeout or partial result. Recalled or archived letters block new attempts, but a request queued earlier may still be processed.

Interpret an attempt's result

Result What it tells you What to check next
Queued The attempt is recorded and waiting for processing. Allow background handling, then refresh.
In progress Manual handling, a partial email outcome or an unresolved provider result may remain. Check the attempt's method and evidence; ask the delivery owner to reconcile uncertainty.
Dispatched The attempt has been recorded as sent or handed off. In the automated email path, this means the counted addresses were accepted by the provider or already had a recorded delivery result. Obtain the confirmation required by your process. It does not prove a person read or acknowledged the letter.
Delivered Delivery has been recorded for this attempt. Examine the evidence and its scope rather than assuming every named recipient acknowledged it.
Failed A failed outcome was recorded. For automatic email this includes no usable email recipients or all tracked recipients having permanent failures. Resolve the cause and agree the next action before sending again.
Returned A returned outcome was recorded for the attempt. Review the reason and evidence with the correspondence team.

The notification service can record provider delivery or bounce callbacks separately from the letter. The current callback path does not automatically update the letter's delivery result. A provider's dashboard and the letter can therefore disagree until authorized reconciliation occurs. Do not keep sending because the letter has not changed to Delivered.

Read all relevant attempts. The current letter summary can display an older delivered attempt even when a newer attempt is queued or failed. The letter's combined state and the displayed summary are not guaranteed to describe the same selection of attempts. A successful-attempt count is also not a count of delivered recipients. These reading limits are explained in delivery summaries and evidence.

Record delivery evidence

Use this action to record an observed outcome; it does not send the letter. A receipt, returned envelope, acknowledgment or transport confirmation should support the particular attempt and outcome you select.

  1. Open the letter and review its existing attempts and evidence.
  2. Choose Record delivery in Letter actions.
  3. In Record delivery evidence?, select Delivery attempt. Check both the method and attempt number; do not select a different attempt simply because it has a similar label.
  4. Choose Delivery outcome. The backend accepts In progress, Dispatched, Delivered, Failed or Returned for an attempt. The inspected screen shows Delivered selected; it does not establish that every choice and failure companion is complete in the frontend.
  5. Optionally enter an Evidence reference, such as a receipt or acknowledgment reference. Keep it within 128 characters while the documented input and storage limits are reconciled.
  6. Optionally enter an Evidence note, up to 512 characters. Explain the outcome and who or what the evidence covers, especially if it covers only part of the intended delivery.
  7. Use Add supporting files if proof is available. Finish the upload before saving. The saved file must come through the governed upload process; a file selected on your computer is not yet proof that its upload completed.
  8. Choose Keep reviewing to return, or Save evidence to record the outcome. Refresh and confirm the new evidence entry belongs to the intended attempt.

Evidence reference, note and files are optional in the current implementation. Saving a Delivered result without files is possible; it remains a recorded assertion and must not be described as independently verified receipt. Your organization's required evidence may be stricter than the form's technical minimum.

Each successful save adds another evidence entry. There is no edit or delete action established by this guide. If you choose the wrong outcome, preserve what happened and ask the responsible team to reconcile it. In particular, once an attempt is Delivered, later evidence does not automatically lower that attempt's state; its latest recorded outcome can differ from the retained Delivered state. Repeated saves are not a safe way to correct uncertainty.

Recording evidence does not change the letter's lifecycle stage. A recalled letter stays recalled even if a delivery result arrives later. Records filing can be requested by the letter's saved policy when an outcome is recorded, but that request is not proof that Records filing has completed. See Send an official letter to Records for selected-file, pending, registration and recovery boundaries.

Recover when delivery is uncertain

Situation What to do
Queue confirmation times out or the page disconnects Reopen the letter and inspect attempts before queuing again. Ask support to reconcile the original request if its result remains unclear.
Email stays In progress Ask the delivery owner to check partial, retryable and uncertain provider results. The status alone does not prove an automatic retry is scheduled.
A provider accepted the email but the letter still looks pending Reconcile the existing attempt and provider evidence. Do not create another attempt solely to obtain a different badge.
No email address exists for a named recipient Arrange an allowed alternative with the correspondence team. An email attempt does not look up a missing address for that recipient.
Portal, courier, physical mail or manual work stays In progress Confirm the external handoff, then record its actual outcome and supporting evidence.
A save rejects an attempt or method Refresh and select an existing attempt for the same letter and method.
Supporting files fail to resolve Complete or recover the upload before retrying the evidence save. Preserve the original attempt and do not substitute an unrelated file.
Evidence save times out Check whether the evidence already appears before saving again; a lost response does not establish failure.
Recall occurs during delivery Coordinate with the delivery owner. Recall does not retract received copies or cancel an already queued provider call.
Evidence conflicts with a Delivered badge Review the full evidence sequence. Escalate the discrepancy rather than using the badge alone to certify completion.

When asking your organization's support or correspondence team for help, provide the letter reference, delivery method, attempt number, action time and the visible result. Share only the information that team needs through an approved channel. Do not include sign-in credentials or unrestricted copies of sensitive correspondence.

For managers and business reviewers

Define who owns each manual handoff, what counts as adequate proof, and who resolves a partial or uncertain email outcome. Distinguish provider acceptance, delivery evidence, recipient acknowledgment and completion of the business obligation. The current implementation does not make those equivalent.

A delivery plan can include several methods, but listing those methods is not a completion checklist enforced by the sender. Agree which recipients and documents each method must cover. Review actual evidence before certifying completion, and verify Records filing independently when retention requires it. This draft supplies no delivery-time commitment, commercial price or legal-service guarantee.

Zerohive documentationStaging draft · 22 Oct 2026

Search documentation

Search guides, platform concepts and tasks.

↑ ↓ to move Esc to close