---
title: Configure project delivery controls
label: Projects and checks
description: Define project roles, enroll recipient devices, require approval and metadata, and validate packages before release.
layout: docs
order: 124
---

Open **Workflows > Projects > New project** within your tenant. An empty project list also offers **Create project**. Enter **Project name** and **Library folder**; **Project ID** is filled from the name and is the identifier used by integrations. Review it before saving.

Use **Add team member**, **Add recipient**, and **Add required field** to create separate form rows. Configure **Release checks**, select connections under **Destinations**, and choose **Release the download link**, then select **Save project** and confirm the folder-wide policy. Use **Edit project** on an existing project to change its rules.

## Assign project roles

| Role       | Purpose                                                          |
| ---------- | ---------------------------------------------------------------- |
| `sender`   | Create jobs and perform permitted retry or cancellation actions. |
| `approver` | Review and approve a prepared manifest as a human operator.      |
| `viewer`   | Inspect project jobs and their evidence.                         |

Project membership is separate from deployment and tenant roles. An automation principal is `automation:TOKEN_ID`, using the issued token's ID. It also needs the appropriate `jobs:read`, `jobs:create`, or `jobs:cancel` permission and a folder scope covering the project directory. A matching folder scope alone does not grant project membership.

Enable required approval when another operator must authorize release. The submitter cannot approve their own job, and automation tokens cannot approve. Approval records the exact manifest and policy revision. Changing policy blocks new admissions for older jobs; create a new job under the revised policy.

## Enroll recipient devices

1. Obtain the recipient's device public key through an authenticated channel. Native recipients can copy it from **Workflows** or run `votport evidence device-key`. Browser recipients use **Copy this browser's device key** on the delivery page.
2. Associate their email address with that key in the project's recipient list. Configure allowed email domains if required.
3. Ask the sender to select the enrolled recipients when queuing the job.
4. Have recipients use the enrolled browser or native device to open the delivery.

Selected recipients must prove possession of their key before file access, on both HTTP and native QUIC paths. Browser and native keys are separate identities; enrolling one does not enroll the other. Browser site-data deletion removes its key and local evidence history. Preserve native identity files in the client's private backup and restore an unreadable key instead of silently replacing it.

The email-to-key association is your enrollment decision. A device signature does not independently verify an email address or prove that a person reviewed the creative content.

## Require the information the next team needs

Under **Delivery information**, select **Add required field** for each metadata key, such as client, episode, version, or purchase_order. A sender supplies those values when creating the job. Under **Release checks**, enable **Require a complete image sequence** when a package must include a specific frame range: prefix, suffix, first frame, last frame, and numeric padding.

For example, use prefix `shot_`, suffix `.exr`, first frame `1001`, last frame `1100`, and padding `4` for the expected `shot_1001.exr` through `shot_1100.exr` sequence. Sequence validation checks the required sequence; it is not a visual review of the images.

## Add media checks and malware scanning

Enable **Check video format** to enter media rules. These inspect the first video stream's codec, dimensions, and rational frame rate with `ffprobe`. Set `VOTPORT_FFPROBE` if the executable is not available by that name. Install it in the server's runtime environment and ensure the service can execute it.

Required malware scanning uses `clamdscan --fdpass`. Install and operate the ClamAV daemon separately, keep its signatures current, and ensure the VOTPort service can reach it. Set `VOTPORT_CLAMDSCAN` to override the executable path. Enabling a project rule does not install the scanner.

A missing, failing, or timed-out required checker withholds release. Each file check has a five-minute timeout and a 64 KiB output bound. Inspect the job error and retry after correcting the cause. Media checks validate the configured technical properties; a successful malware scan is not a guarantee that all threats are absent.

Library media and scanning jobs use private snapshots; reception jobs check their pinned received originals without another payload copy. [Storage guidance](/docs/self-hosting/storage/#workflow-storage-and-private-snapshots) covers capacity, retention, and S3 import/export. Select up to 16 destinations and choose **After all destinations finish** to require every copy before local release, or **After local checks and approval; copy in the background** to release locally first.

## Keep delivery control consistent

Protected project directories cannot be shared through an ordinary link to bypass the project rules. Release and recipient checks cover metadata, files, ranges, bundles, download leases, and native admission. A rotated share invalidates its earlier token and QUIC tickets; already admitted streams may finish.

Keep signed events and recipient evidence with the project record. Use [workflow events](/docs/administration/workflow-events/) to connect approval, release, acceptance, and deadline handling to your existing systems.

## Apply the project to incoming files

Enable **Use this project for incoming files**, then select it under **Receive > After files arrive > Reception project**. The receive request supplies the project's required metadata and recipient selections. Only completed uploads queue reception jobs; incomplete packages remain withheld from raw sharing.

Project API documents use `receive` to enable incoming use, `destinations` for connection IDs, and `release` as `all_destinations` (default) or `local`. Read the current revision before changing policy. Changes do not synchronize to another port: its own receive request, tenant, quota, and project remain authoritative. See [reception setup](/docs/using/reception/).