---
title: Prepare, release, and track a delivery
label: Delivery workflows
description: Create persistent delivery jobs with project checks, human approval, schedules, and signed recipient acceptance.
layout: docs
order: 125
---

Use a delivery workflow when a package needs required metadata, checks, approval, enrolled recipients, or a recorded acceptance deadline. Jobs persist across server restarts, so preparation and reporting do not depend on keeping a browser tab open.

Open **Workflows** in your browser or the macOS or Windows app. Update the server and clients together; a server update does not update installed desktop screens or the bundled MCP executable.

The browser workspace has four sections: **Deliveries**, **Projects**, **Webhooks**, and **Activity**. Storage connections and agent tokens have their own **Storage** and **Automation** pages. Older desktop links to `/deliver#workflows` redirect to the new Workflows page.

## Create a delivery job

1. In the browser, select **New delivery**, then choose a project. Your administrator defines its library folder, membership, recipient enrollment, and release rules.
2. Enter the **Delivery name**, required metadata, and **Link expires after (days)**. Select the intended enrolled recipients; projects with enrolled recipients require at least one selection.
3. Under **Timing**, set an optional **Scheduled start** and **Acceptance deadline** in your local time zone. Under **Source files**, choose a connection in **Read files from** to import from S3, then enter **Folder in storage** relative to that connection’s root folder. Leave **Project library folder** selected to use the library.
4. Select **Create delivery** and follow the card in **Deliveries**. It shows preparation, check errors, approval, and storage-export progress. Use **Refresh** to fetch current status.
5. Select **Copy download link** once the job is released. Checks and required approval always finish before release. By default every destination must also finish; projects can instead release locally and copy in the background.

Desktop apps create and inspect jobs, approve eligible manifests, retry failures, and cancel jobs. Their **Project rules, schedules, storage and events** link opens the browser for configuration and scheduling.

The project uses a frozen policy revision and an ordered manifest of filenames, VOT identities, sizes, and positions. Keep source files unchanged. A modified file cannot silently become part of an already approved package.

## Read the job state

| State                  | What to do                                                                                                    |
| ---------------------- | ------------------------------------------------------------------------------------------------------------- |
| `queued`               | Wait for the scheduled start and preparation capacity.                                                        |
| `preparing`            | VOTPort is preparing the manifest and running the required checks.                                            |
| `awaiting_approval`    | A different authorized human operator must review and approve this exact manifest.                            |
| `exporting`            | Destination copies are running; a local-release project may already expose its link.                          |
| `ready`                | Preparation is complete. Use the returned URL only while the grant and current project policy permit release. |
| `retrying`             | A failed destination is waiting for its next automatic attempt.                                               |
| `failed`               | Inspect the error, correct the cause, then explicitly retry.                                                  |
| `cancelled`            | Further file admissions are blocked. Previously admitted transfers may finish.                                |
| `retiring` / `retired` | Private snapshots are removed and reception source pins released; job history and evidence remain.            |

Automatic recovery is bounded to five worker attempts per retry cycle. Successful destinations are preserved across retries; explicit **Retry** starts another cycle. An explicit retry keeps the original request and frozen identities. Use a new job when the intended files or policy need to change.

## Receive and distribute automatically

A project can also start from completed incoming uploads. Enable its receiving option and attach it to a request. Choose up to 16 S3, shared-folder, or VOTPort destinations and whether local release waits for all copies. The delivery card shows each destination's progress, custody evidence, and revocation status. See [reception workflows and trade routes](/docs/using/reception/).

## Review and approve release

For projects requiring approval, open **Package and recipient verification** on the delivery card to review its manifest, then select **Approve delivery** and confirm release. Approval must come from a different human operator than the submitter. It binds both the manifest and project policy revision. Automation tokens cannot approve, even when they can create or cancel jobs.

A project policy change blocks further admissions for jobs prepared under the previous revision. Create a new job under the new policy. Ordinary sharing cannot bypass a protected project folder.

## Schedule work and track deadlines

A scheduled job starts at or after its `not_before` time; it is not a guarantee of completion by that time. Preparation, checks, and approval still need to finish, along with any destinations required by the release rule.

An acceptance deadline produces one durable `delivery_deadline_missed` event if any selected recipient has not accepted. For a job without selected recipients, any recorded acceptance satisfies the deadline. Cancelled jobs do not escalate. Use [signed events and webhooks](/docs/administration/workflow-events/) to notify your production system or flag an overdue handoff.

## Know what the recipient confirmed

File verification and recipient acceptance are separate records. Native receivers queue signed verification after checking and publishing the local files. The recipient then explicitly accepts the verified package. Browser recipients choose their saved files for hashing before acceptance becomes available.

On the browser delivery card, expand **Package and recipient verification**, then select **Load recipient evidence**. Use **Load more evidence** to retrieve additional records and **Export signed evidence** to save a loaded batch as JSON. MCP provides the same records through `get_job_evidence`. A download counter does not replace these statements. See [recipient verification and acceptance](/docs/using/verification/#confirm-recipient-verification-and-acceptance) for the full process and what each signature proves.

## Recover a job without duplicating it

CLI and API integrations must choose a stable `operation_id` before creating a job. Repeat the same request with the same actor and ID after a lost response; it returns the existing job. Reusing the ID with different fields fails.

The browser retains a pending creation request in the tab’s session storage after an uncertain response. Retry its original fields to recover that delivery. **Discard pending draft** allows a separate request; it does not cancel a job that the server may already have created. Check the delivery list before intentionally starting another one.

Retrying evidence submission does not download the payload again. Cancelling a job or revoking its link cannot recall files already delivered. Read the [automation guide](/docs/using/automation/) for job commands, permissions, and all 15 MCP tools.