Configure project delivery controls
Define project roles, enroll recipient devices, require approval and metadata, and validate packages before release.
On this page
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
- 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. - Associate their email address with that key in the project's recipient list. Configure allowed email domains if required.
- Ask the sender to select the enrolled recipients when queuing the job.
- 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 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 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.