DeliveryRequest

A Delivery Request represents a request for files or information: you request someone to deliver something.

Property Reference

This is a table of the properties of a DeliveryRequest object. Some of these are explained in more detail below.

Field Name	Required	Type	Description	Format
activeStatus	✘	String	Is the request active, or is it archived?	Enum: Active, Archived,
allowFlowTransfer	✘	Boolean	Is the request allowed to transfer material to Limecraft Flow, or should it transfer to a linked VolumeAccess?
allowMultipleSubmissions	✘	Boolean	Make it possible for multiple submissions to be “active” (not in an end-state APPROVED or REJECTED) at the same time.
assignee	✘	DeliveryRequestAssignee
clientProperties	✔	Object
continueFromPreviousSubmission	✘	Boolean	This property influences if a new DeliveryRequestSubmission in the request dialog starts empty (if false) or starts from a clone of the last submission (if true). It is not interpreted by the API, but should be implemented by the client UI.
created	✘	Date	The time when this resource was created	date-time
createdBy	✘	String	The request or process that created this resource
creatorId	✘	Long	The id of the user who created this resource	int64
deliveryDate	✘	Date	When should this request be delivered?	date-time
deliveryRequestType	✔	String	This should be a unique identifier of this type of request. When integrating with Limecraft Flow DeliveryRequests, you can use this property to check the type of request you are dealing with (rather than for instance use the group and subGroup fields). We strongly advise to only use alphanumerical characters and dashes to create a deliveryRequestType handle. Special characters, accents etc. should be avoided.
description	✔	String	A plain-text description of what is expected to be provided in the request. It can be shown to the user as information.
editorialObject	✘	EditorialObject
editorialObjectId	✘	Long		int64
expectedDeliveryDate	✘	Date	When do we expect this request be delivered?	date-time
formFieldValues	✘	Object
formFieldsDefinition	✘	FormFieldsDefinition
group	✔	String	Used to organize DeliveryRequests, but the value itself is not interpreted by the system.
hideDeliveryDate	✘	Boolean	Is a client user interface not allowed to show the delivery date?
id	✔	Long	The id of this resource	int64
label	✔	String	A human readable label for the DeliveryRequest. This can be shown to the user.
lastSubmissionApprovedDate	✘	Date	Date of approval of the last submission	date-time
lastUpdated	✘	Date	The time when this resource was last updated	date-time
layout	✔	Object
metadataOnly	✘	Boolean	When true, the request will not ask for file uploads. It will only show a metadata form.
modifiedBy	✔	String	The request or process responsible for the last update of this resource
objectType	✘	String	The data model type or class name of this resource
productionId	✘	Long		int64
reviewer	✘	DeliveryRequestReviewer
showPreviousSubmissions	✘	Boolean	Influences if the version sidebar in the request dialog is shown or not.
subGroup	✔	String	Used to organize DeliveryRequests, but the value itself is not interpreted by the system.
submissionStatus	✘	String	The status the DeliveryRequests last DeliveryRequestSubmission is in.	Enum: Open, Draft, AwaitingProbe, AwaitingAutoValidation, AwaitingDelivery, AwaitingReview, Accepted, Rejected, DraftFailed, DeliveryFailed,
submissions	✘	Set of DeliveryRequestSubmission
submitLocked	✘	Boolean	Marks the request as being "submission locked". This will not allow submit on existing DeliveryRequestSubmissions and will not allow creating new DeliveryRequestSubmissions
tag	✘	Set of string
templateId	✘	String
validationRules	✔	ValidationRules
version	✔	Long	The version of this resource, used for Optimistic Locking	int64
volumeAccesses	✘	Set of VolumeAccess	When not uploading to Flow, the transfer will upload to one of the VolumeAccesses in here.

Field Name

Required

Type

Description

Format

activeStatus

✘

String

Is the request active, or is it archived?

Enum: Active, Archived,

allowFlowTransfer

✘

Boolean

Is the request allowed to transfer material to Limecraft Flow, or should it transfer to a linked VolumeAccess?

allowMultipleSubmissions

✘

Boolean

Make it possible for multiple submissions to be “active” (not in an end-state APPROVED or REJECTED) at the same time.

assignee

✘

DeliveryRequestAssignee

clientProperties

✔

Object

continueFromPreviousSubmission

✘

Boolean

This property influences if a new DeliveryRequestSubmission in the request dialog starts empty (if false) or starts from a clone of the last submission (if true). It is not interpreted by the API, but should be implemented by the client UI.

created

✘

Date

The time when this resource was created

date-time

createdBy

✘

String

The request or process that created this resource

creatorId

✘

Long

The id of the user who created this resource

int64

deliveryDate

✘

Date

When should this request be delivered?

date-time

deliveryRequestType

✔

String

This should be a unique identifier of this type of request. When integrating with Limecraft Flow DeliveryRequests, you can use this property to check the type of request you are dealing with (rather than for instance use the group and subGroup fields). We strongly advise to only use alphanumerical characters and dashes to create a deliveryRequestType handle. Special characters, accents etc. should be avoided.

description

✔

String

A plain-text description of what is expected to be provided in the request. It can be shown to the user as information.

editorialObject

✘

EditorialObject

editorialObjectId

✘

Long

int64

expectedDeliveryDate

✘

Date

When do we expect this request be delivered?

date-time

formFieldValues

✘

Object

formFieldsDefinition

✘

FormFieldsDefinition

group

✔

String

Used to organize DeliveryRequests, but the value itself is not interpreted by the system.

hideDeliveryDate

✘

Boolean

Is a client user interface not allowed to show the delivery date?

✔

Long

The id of this resource

int64

label

✔

String

A human readable label for the DeliveryRequest. This can be shown to the user.

lastSubmissionApprovedDate

✘

Date

Date of approval of the last submission

date-time

lastUpdated

✘

Date

The time when this resource was last updated

date-time

layout

✔

Object

metadataOnly

✘

Boolean

When true, the request will not ask for file uploads. It will only show a metadata form.

modifiedBy

✔

String

The request or process responsible for the last update of this resource

objectType

✘

String

The data model type or class name of this resource

productionId

✘

Long

int64

reviewer

✘

DeliveryRequestReviewer

showPreviousSubmissions

✘

Boolean

Influences if the version sidebar in the request dialog is shown or not.

subGroup

✔

String

Used to organize DeliveryRequests, but the value itself is not interpreted by the system.

submissionStatus

✘

String

The status the DeliveryRequests last DeliveryRequestSubmission is in.

Enum: Open, Draft, AwaitingProbe, AwaitingAutoValidation, AwaitingDelivery, AwaitingReview, Accepted, Rejected, DraftFailed, DeliveryFailed,

submissions

✘

Set of DeliveryRequestSubmission

submitLocked

✘

Boolean

Marks the request as being "submission locked". This will not allow submit on existing DeliveryRequestSubmissions and will not allow creating new DeliveryRequestSubmissions

tag

✘

Set of string

templateId

✘

String

validationRules

✔

ValidationRules

version

✔

Long

The version of this resource, used for Optimistic Locking

int64

volumeAccesses

✘

Set of VolumeAccess

When not uploading to Flow, the transfer will upload to one of the VolumeAccesses in here.

deliveryRequestType

A Delivery Workspace will often contain multiple requests which ask for the same kind of thing, but e.g. for different episodes. For example, "the finished master" of episodes 1 up to 10.

The type of request is uniquely identified by the deliveryRequestType. The configuration of a request can be vastly different for a different deliveryRequestType.

When integrating with Limecraft Flow DeliveryRequests, you can use this property to check the type of request you are dealing with.

We strongly advise to only use alphanumerical characters and dashes to create a deliveryRequestType handle. Special characters, accents etc. should be avoided.

Examples:

episodeMetadata
episodePromoTrailer
seriesPromoImages
seriesMetadata

Configuration Properties

metadataOnly

When true, the request will not ask for file uploads. It will only show a metadata form.

Example of a request which does not ask for files, but only for information.

Metadata only request

formFieldsDefinition

In the user interface, the Delivery Request dialog can show a form of fields that should be filled in for a submission. This form, defined in formFieldsDefinition is highly configurable, and can be used to request various metadata. Some examples:

a form field to capture the title of the episode
a form field to capture cast members (first name, last name and role)
a form field to list time codes where commercial breaks can be inserted

A "FormFieldsDefinition" is a Limecraft Flow concept which is used in various places of our API, and is not limited to Delivery Requests. Learn more about it in the section on Form Fields.

A formFieldsDefinition is used to define the structure of the data and the kind of fields that the form should show. The actual layout of the form is defined using the layout property of a DeliveryRequest.

layout

By default, the fields defined in formFieldsDefinition will be rendered as a flat list of fields.

The layout gives you control over exactly how the fields are layed out in the form. This can be used to have multiple columns, or insert some text in between etc.

Learn more about it in the section on Configure a layout.

allowFlowTransfer

A Delivery Request can be configured to expect files to be delivered. Exactly how these files are transfered depends on the allowFlowTransfer flag and the available volumeAccesses.

If allowFlowTransfer=true, the material uploaded in a request dialog will first be transferred from the browser to Limecraft Flow. The actual delivery (after submitting the request) will then transfer this material from Limecraft Flow to the on-premise storage using the Cloud Connector.

A request with allowFlowTransfer set to true

The alternative is allowFlowTransfer=false. In that case, the request will upload material to a VolumeAccess which should be available in the DeliveryRequests’s volumeAccesses. Today, the application will expect a VolumeAccess with protocol "AsperaConnect" to be available, and will use that to transfer.

A request with allowFlowTransfer not set to true

A request without allowFlowTransfer set to true

Both approaches have their advantages and drawbacks.

Only material transferred to Flow will get thumbnails, and can be used for Review in Limecraft Flow.
Transfer to Flow introduces some extra delay and costs, as material needs to go over the Limecraft Flow platform.

showPreviousSubmissions

This property influences if the version sidebar in the request dialog is shown or not.

Show Previous Submissions

Do Not Show Previous Submissions

continueFromPreviousSubmission

This property influences if a new version (a new submission) in the request dialog starts empty (if false) or starts from a clone of the last submission (if true).

allowMultipleSubmissions

The default behaviour (allowMultipleSubmissions=false) is to have at most one DeliveryRequestSubmission not in an end-state, see this section. A new DeliveryRequestSubmission can not be created unless all previous ones their submissionStatus is either ACCEPTED or REJECTED. The exception “Can not create more submissions, unless all previous are either accepted or rejected." will be thrown when trying to do so.

When allowMultipleSubmissions=true, it is possible for multiple DeliveryRequestSubmissions to be “active” (not in an end-state APPROVED or REJECTED) at the same time. Even with this flag, it is not allowed to have multiple unsubmitted (OPEN, DRAFT submissionStates) DeliveryRequestSubmissions at the same time.

Note that this behaviour could result in the DeliveryRequestSubmissions to arrive out of order on the receiver end (e.g. submit a very large file which is still transferring, followed by a new submission of a small file). The receiver end could use submissionVersion to ignore events of previous submissions.

Note that multiple DeliveryRequestSubmissions can be in AWAITING_REVIEW at the same time.

The submissionStatus of the DeliveryRequest is based on the submissionStatus of the last DeliveryRequestSubmission, regardless of the value of allowMultipleSubmissions.

validationRules

The validationRules are used to check whether what the user submits on the DeliveryRequest is what we expect. It makes it possible to decline certain submissions automatically.

Learn more about it in the section on Validation of a Delivery Request Submission.

clientProperties

These are some additional properties which influence the user interface of the request dialog.

Client Property Description

Client Property	Description
`allowMultipleSelection`	`true` - multiple files can be selected in the file input `false` - only a single file can be selected `unset` - false
`fileInputAccept`	An array of extensions (has to start with '.') which can be selected. In case of a Limecraft Flow upload, mime types can be used as well, following html accept attribute. In case of Aspera upload, the extensions are expected to start with a dot, and will be converted to the appropriate format.
`asperaAllowedFileTypes`	Allows directly passing the Aspera `allowedFileTypes` option. Use of `fileInputAccept` with a list of extensions is preferred to this (as it’ll work for both Limecraft Flow upload and Aspera upload).

allowMultipleSelection

true - multiple files can be selected in the file input
false - only a single file can be selected
unset - false

fileInputAccept

An array of extensions (has to start with '.') which can be selected.

In case of a Limecraft Flow upload, mime types can be used as well, following html accept attribute.

In case of Aspera upload, the extensions are expected to start with a dot, and will be converted to the appropriate format.

asperaAllowedFileTypes

Allows directly passing the Aspera allowedFileTypes option.

Use of fileInputAccept with a list of extensions is preferred to this (as it’ll work for both Limecraft Flow upload and Aspera upload).

group, subGroup

These properties are just plain string labels. They are used to organize the requests, but their value itsself is not interpreted by the system.

In the Limecraft Flow UI, group is called "Category" and subGroup is called "Subcategory"

The group ("Category") can be used as a filter. In the background you also see grouping on both group and subGroup.

filtering and grouping on group and subGroup

submitLocked

This field starts with a value of false, but it can be set by a user with the permission`DELIVERY_REQUEST_REVIEW` to true to "lock" the request. It is also possible to turn it back to false to "unlock" the request.

Once locked

it is no longer possible to create a new DeliveryRequestSubmission
- in the UI, ‘Create New’ / ‘Modify’ buttons will not be available
it is no longer possible to submit an existing unsubmitted DeliveryRequestSubmission (if one exists)
- UI will not show Submit button
editing the existing DeliveryRequestSubmission is still possible but does not make much sense
- UI will render the form with read only fields
It is still possible to Approve / Reject a locked request

submissionStatus

Delivery Requests start their life cycle in the Open submissionStatus without any DeliveryRequestSubmissions.

Once the DeliveryRequest has one or more DeliveryRequestSubmissions, its submissionStatus will be the state of the last non-archived DeliveryRequestSubmission.

formFieldValues

The Delivery Workspace can define Form Fields for its DeliveryRequests by setting the deliveryRequestFormFieldsDefinition (to a valid FormFieldsDefinition).

Then, each DeliveryRequest will have these fields. The values of them can be set in the formFieldValues property (to valid FormFieldValues).

These form fields are defined on the workspace level, and the values set on the DeliveryRequest level. Do not confuse with the form fields defined on the DeliveryRequest level (using formFieldsDefinition) of which the values are set on the DeliveryRequestSubmission’s formFieldValues.

deliveryDate

When set, it represents the due date when the requested files and information should be provided. See this page to learn how to change it.

Example 1745359200000.

expectedDeliveryDate

When set, it represents when the supplier expects to be able to supply the requested files and information. See this page to learn how to change it.

Example 1745359200000.

assignee

It represents the user or role responsible for fulfilling the request. When set, it is an object with either a userId or a roleId.

reviewer

It represents the user or role who should review DeliveryRequestSubmissions on the DeliveryRequest. When set, it is an object with either a userId or a roleId.