Approve, issue and close an official letter¶

An official letter moves through separate decisions: prepare its content, approve it when required, issue it, then arrange delivery and any follow-up work. These stages help teams explain who made a decision and what has actually happened. Approval alone does not send the letter. Issue assigns its official reference; delivery and filing need their own evidence.

Availability: this guide describes the intended WorkOS Final Screens journey and the implemented service rules inspected on 8 October 2026. The frontend action page is a sample preview whose links change the displayed state. Connected actions, complete recovery screens and availability in your workspace have not been verified. Treat the steps as the intended journey, not confirmation that the preview performs them.

Use Prepare an official letter for content and recipients, and Read an official letter for its history, attachments and delivery evidence.

For record preservation after issue or a delivery event, see Send an official letter to Records. A request, a registered record and completed filing are separate outcomes.

Before making a decision¶

Open Correspondence → Official letters, select the correct letter and review its content, recipients, attachments, current status and Letter actions. Check the organization and any linked approval process before acting. A letter that another person has changed may no longer allow the action you were about to take.

Your organization must give you access to manage official letters. Reading access alone does not grant these actions. The current service uses the same management permission for drafting and lifecycle decisions; the visible approver or signing-authority description does not itself enforce a separate decision-maker role. Administrators and process owners should agree who may exercise that permission. This guide does not grant access or establish a formal signature process.

Use a short, meaningful remark that explains your decision. The inspected service requires a remark for these action forms, although several design dialogs label it optional. Long remarks can also fail because the form and saved history currently use different length limits. That discrepancy remains open; do not rely on the form accepting a long note as proof that it can be saved.

Understand the stages¶

Delivery labels such as In progress or Delivered describe a separate delivery condition. A delivered letter can still be at the Issued stage. Read the delivery and evidence guidance before interpreting a summary as proof that every recipient received it.

Submit a saved draft¶

1. Open the draft and finish reviewing the content, recipients and attachments. Use Edit draft if something needs correction.
2. Choose Submit letter in Letter actions.
3. In Submit letter?, enter a Submission remark explaining why the letter is ready. Choose Keep editing to return without confirming.
4. Choose Submit letter, then check the refreshed letter and history.

If approval is required, the letter becomes Awaiting approval and requests its configured approval process. If approval is not required, submission moves it directly to Approved. Both paths end draft editing. Neither issues or delivers the letter.

The dialog currently says submission always starts approval. That wording needs correction for the no-approval path. A successful submission also does not mean the linked process has already started: its reference may appear later. If it does not appear, use the recovery guidance below rather than submitting again as a new action.

Submitting a newly prepared letter has an additional save stage. If that journey fails, a draft may already exist; follow save and submission recovery before recreating it.

Approve the letter for issue¶

1. Open a letter that is Awaiting approval and read the full content and supporting material.
2. Choose Approve letter.
3. In Approve this letter?, enter an Approval remark for the issuing team. Choose Keep reviewing if you are not ready.
4. Confirm Approve letter, then check that the letter is Approved and that its history records the decision.

Approval records the decision, actor and time. It does not assign the official reference, issue the letter, sign a document or arrange delivery. A linked approval workflow can also approve the letter when that process completes.

A direct approval does not itself finish the separate workflow. If that workflow later rejects the letter while it is still Approved, the letter can become Rejected. Coordinate with the process owner instead of treating the two decision paths as independent approvals that can safely proceed in parallel.

Issue the approved letter¶

1. Open the Approved letter and confirm that the content and recipients are final.
2. Choose Issue letter.
3. In Issue this letter?, enter an Issue remark for the delivery team. Choose Keep reviewing if anything needs checking.
4. Confirm Issue letter. Check the resulting Issued stage, official reference and issue entry in history.

Issue is the point at which the system allocates the official reference. A reference shown on a design example before this point is not evidence that a real draft has one. The current lifecycle does not provide editing or reissue after issue.

Issue makes delivery eligible; a delivery attempt must still be requested and its outcome checked. If the draft was configured to start an operational workflow on issue, issue requests that work. An applicable automatic filing policy can also request a Records entry. Those requests do not prove that the workflow or record already exists. Some filing policies require a trusted attached document and can prevent issue when that prerequisite is missing. Ask the correspondence owner to resolve the configuration or document requirement if the action fails.

Reject a letter¶

1. Review the letter and record what prevents approval or issue.
2. Choose Reject letter where that action is available.
3. In Reject this letter?, enter the Reason for rejection. Choose Keep reviewing to return without confirming.
4. Confirm Reject letter, then check the Rejected stage and recorded decision.

The service accepts rejection while Awaiting approval or Approved. The inspected Approved design does not show the rejection action, so that entry point still needs reconciliation.

Rejection does not make the letter editable again. The dialog's promise that the author can update the draft and return it for approval is not supported by the current lifecycle. If a corrected letter is needed, coordinate with the correspondence owner to prepare a new draft and, where appropriate, reference the earlier letter. There is no verified automatic copy or reopen operation. Direct rejection also does not cancel an already-running approval workflow.

Start follow-up work¶

Use follow-up work when an issued letter needs a separate operational process, such as tracking an instruction. The letter must still be Issued; proof of delivery is not a prerequisite enforced by this action.

1. Open the issued letter and check its linked workflows first. Issue may already have requested the configured process.
2. Choose Start follow-up workflow.
3. In Start a follow-up workflow?, select the Workflow definition and enter a short Workflow remark. Use Keep viewing to return without starting.
4. Choose Start workflow, then check for the linked process and its actual state as processing completes.

This action starts operational work. Approval workflows are requested by submitting a draft; this is not an alternate approval button. If the required definition is unavailable, ask the process owner to check it. The design shows a chosen definition, while the service can use the saved operational definition when no override is supplied.

The current implementation requires the workflow remark in the form but does not retain it in the start request or letter history. Do not use that field as the only record of an instruction or decision. The discrepancy is tracked for correction.

A successful start request is not proof that the process has started. Repeating a fresh request can start additional work, so do not repeat it simply because the link has not appeared. Check the existing letter and workflow evidence with the process owner first.

Recall an issued letter¶

1. Open the Issued letter, review delivery activity and linked work, and identify why it must be withdrawn.
2. Choose Recall letter.
3. In Recall this letter?, enter the Recall remark. Use Keep viewing to return without recalling.
4. Confirm Recall letter and check the Recalled stage and recall entry.
5. Follow up separately on linked workflows and any delivery already requested or completed.

Recall blocks new delivery attempts and new workflow starts for that letter. It does not retract a copy already received, remove a recipient's knowledge of its contents or demonstrate that an existing delivery attempt has stopped. Contact the responsible team through your organization's established process when recipients need a correction.

The saved recall policy determines what happens to linked work. If cancellation is configured, the system requests cancellation of active linked workflows. If it is not configured, those workflows can continue. Cancellation requested and cancellation completed are different outcomes. Work that starts after the recall can also receive a cancellation request, but this still needs a later outcome. Previously completed tasks are not undone.

There is no same-letter undo-recall or reissue action in the inspected lifecycle. Retain the reason and discuss any replacement letter with the correspondence owner.

Archive a letter¶

1. Check whether the letter has unfinished delivery or linked work and agree how the responsible team will handle it.
2. Choose Archive letter.
3. In Archive this letter?, enter the Archive remark. Choose Keep viewing if closure is premature.
4. Confirm Archive letter, then check the Archived stage and closure entry.

Archive is available for any letter that is not already archived, including an unissued draft or a recalled letter. Archiving a draft does not issue it or assign a reference. Archive does not automatically create a Records entry, cancel workflows, recall delivered copies, delete attachment bytes or impose a retention policy.

The inspected dialog describes archive as read-only. The current implementation has a more limited boundary: editing and ordinary lifecycle progression stop, while eligible delivery evidence, Records linking and existing workflow outcomes can still update information. There is no unarchive operation. Check the specific history and linked evidence instead of assuming archive freezes every field.

Recover when an action is uncertain¶

Managers should use the letter history, delivery evidence, linked workflow and Records entry together when confirming an outcome. None of those alone proves all the others. Use your organization's established support route for escalation, and the correspondence overview for the remaining availability limits.