MM5.6 Setting up download request workflow

Roles

For the roles required to configure workflows and automations, as well as the roles required for other workflow-related functions (such as viewing the task list, transitioning a stage or ability to request download) please refer to: DC 5.5 Roles.

Download request workflow covers the steps in an asset life cycle concerning the use of the existing assets.

An example of a correctly configured download approval flow presented here consists of two stages. In the first stage, the administrator configures the download request workflow. It is here where the administrator can decide on all the criteria that limit the download of assets. The second stage is an additional configuration in the general settings of the Media Manager. In some cases, it might be necessary to perform other configurations prior to setting up the workflow, for example creating additional metadata fields.

The following elements are required for a functional approval process:

  • A workflow with a minimum of three stages: a pending stage, an approved stage, and a rejected stage.

  • Enabling the download request in the settings of the Media Manager.

All other elements are optional, though some might be heavily recommended, as it will be indicated in the detailed descriptions of the stages below.

Part 1 Workflow

The basic download approval workflow consists of three stages: a pending stage, an approved stage, and a rejected stage.

It is also, for example, possible to create a loop from the rejected stage back to the pending stage, if reconsideration should be possible (not included in this example of workflow configuration). For instance, if the reason for rejection is insufficient information provided by the requesting user, this can be fixed by communicating through the comments section of the task. If the conditions for approval are then met, the user responsible for the task can approve the previously rejected request.

Please do not enable ā€œLimit this workflow to one task per itemā€œ, as this will only allow only one user to request downlad

Configuration:

Step

Configuration

Explanation

Step

Configuration

Explanation

ā€œRequest downloadā€ transition

Name: selected by the user

Transition type: Manual

Unique ID: selected by the user

Description: selected by the user (optional)

Constraints: execution condition, string input constraints, date input constraint

The transition is manual, because it is initiated by a deliberate action from a user - in this case, a request for asset download.

ā€œAny user can transitionā€ constraints is selected to enable any user with the ability to download assets to make the request without having to have additional roles in the system.

The input constraints is what builds the request form. In this case, the requesting user will be asked to state their name, their origin, reason for downloading and the deadline for the request.

ā€œPending approvalā€ stage

Name: selected by the user

Unique ID: selected by the user

Description: selected by the user (optional)

Mark as completed: no

Relevant Meta Fields: -

Stage owner: Assign to instance owner

Labels: selected from the list of created as custom

The name of the stage is also the name of the task.

The optional description will provide the assigned user with the explanation of what is expected in this stage.

In this case, the stage owner is the content owner (the person responsible for the management of a particular asset). The configuration requires selecting the correct MIR metadata field, where the content owner is stated. For more information, please refer to the information box about dynamic assignment, located under the table.

The label will be displayed on the task.

ā€œApproveā€ transition

Name: selected by the user

Transition type: Manual

Unique ID: selected by the user

Description: selected by the user (optional)

Constraints: upload constraint

The manual transition means that the task can only be fulfilled by selecting one of the options from the list of available actions.

Constraint:

  • ā€œUpload File Constraintā€ - the user assigned to the task needs to upload a file meeting certain criteria (here: a pdf document) before approving the the request.

ā€œApprovedā€ stage

Name: selected by the user

Unique ID: selected by the user

Description: selected by the user (optional)

Mark as completed: yes

Relevant Meta Fields: -

Stage owner: Unassigned

Labels: selected from the list of created as custom

The name of the stage is also the name of the task.

The optional description will provide the assigned user with the explanation of what is expected in this stage.

The label will be displayed on the task.

Marking the stage as complete means that the this particular workflow instance will be archived after this stage.

ā€œRejectā€ transition

Name: selected by the user

Transition type: Manual

Unique ID: selected by the user

Description: selected by the user (optional)

Constraints: string input constraint

The manual transition means that the task can only be fulfilled by selecting one of the options from the list of available actions.

Constraint:

  • ā€œString Input Constraintsā€ - the person responsible for the task needs to explain the reason for rejecting the download request.

ā€œRejectedā€ stage

Name: selected by the user

Unique ID: selected by the user

Description: selected by the user (optional)

Mark as completed: yes

Relevant Meta Fields: -

Stage owner: Unassigned

Labels: selected from the list of created as custom

The name of the stage is also the name of the task.

The optional description will provide the assigned user with the explanation of what is expected in this stage.

The label will be displayed on the task.

Marking the stage as complete means that the this particular workflow instance will be archived after this stage.

Ā 

Dynamic stage owner assignment

Dynamic stage assignment of owner is a functionality created for the systems where each asset has a content owner in mind. In order for this to be configured there needs to be a metadata field with the following properties:

  • Field type: MasterItemReference

  • Item type: Member of Member_Group

This is how the resulting field will look like in Media Manager:

Part 2 Settings

After the workflow is correctly configured, it needs to be enabled before it takes into effect. In order to enable the workflow, the administrator needs to navigate to Settings ā†’ General settings ā†’ Download approval.

Here, the users needs to toggle the button for enabling approval of download requests, select the workflow from the drop-down list and specify the approved and denied stages.

All other options are optional and allow for greater flexibility of the download request functionality. Here, the administrator can choose:

  • whether certain formats should be whitelisted or specifically require approval

  • if a metadata field should control whether whole assets should be whitelisted or specifically require approval for download

  • if there is a content owner who should never be required to request the download of the assets they are responsible for.

Bypassing download approval

There are four ways of bypassing download approval when itā€™s enabled.

1. Bypass based on a boolean metadata field

As mentioned earlier in the previous section of the page, there exists an option to select a boolean metadata field to determine, if an asset is available to download for all who have the download role.

This can be configured under Select metafield section of the settings by selecting the option Bypass approval and then specifying the metadata field. All users must have read access to the metadata field.

2. Bypass based on media formats

It is also possible to specify which media can always be downloaded by all users with the ability to download assets.

This can be configured under Media formats section of the settings by selecting the option Bypass approval for selected formats and then specifying one or more formats below.

3. Bypass based on a role

If the user or user group has the role Download_Approval_Bypass, this will grant those users the ability to bypass all download approval restrictions.

4. Bypass based on groups or users (Content Owner)

This allows users or user groups to bypass the download approval process for only the assets they are responsible for.

Please be aware that the person who is entrusted with the ability to bypass the download, will also need to have read access to the MasterItemReference field which is used to determine who can bypass the download. It is the same field as described in the information box ā€œDynamic stage owner assignmentā€. However, this field may be hidden.

Require download approval

Just like there is the ability to bypass download approval, we also offer the reversal of this - which is requiring download approval only under certain circumstances.

There exist two possibilities:

1. Require based on a boolean metadata field

There exists an option to select a boolean metadata field to determine, if all users need to request download of a particular asset.

This can be configured under Select metafield section of the settings by selecting the option Require approval and then specifying the metadata field.

2. Require based on media formats

It is also possible to specify which media formats need to be requested before download by all users, despite their ability to download assets.

This can be configured under Media formats section of the settings by selecting the option Require approval for selected formats and then specifying one or more formats below.

Combining the metafield and media formats

Below are shown the 8 valid scenarios which you can configure the download request.

All users have to request all assets

Metafield = Any
Metafield data = [Empty]
Formats = Bypass
Formats data = [Empty]

All users have to request all assets except selected assets

Metafield = Bypass
Metafield data = Bit field
Formats = Bypass
Formats data = [Empty]

All users have to request all assets except for selected formats

Metafield = Any
Metafield data = [Empty]
Formats = Bypass
Formats data = Selected formats

All users have to request all assets except selected assets and selected formats

Metafield = Bypass
Metafield data = Bit field
Formats = Bypass
Formats data = Selected formats

No users have to request any assets

Disable download request altogether

No users have to request any assets except selected assets

Metafield = Require
Metafield data = Bit field
Formats = Bypass
Formats data = [Empty]

No users have to request any assets except selected formats

Metafield = Bypass
Metafield data = [Empty]
Formats = Require
Formats data = Selected formats

No users have to request any assets except selected assets and selected formats

Metafield = Require
Metafield data = Bit field
Formats = Require
Formats data = Selected formats

Ā 

Ā 

Ā