MM5.9 Setting up download request workflow
- Mathias Mattson (MHM)
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 |
|---|---|---|
“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:
|
“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:
|
“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 |
All users have to request all assets except selected assets | Metafield = Bypass |
All users have to request all assets except for selected formats | Metafield = Any |
All users have to request all assets except selected assets and selected formats | Metafield = Bypass |
No users have to request any assets | Disable download request altogether |
No users have to request any assets except selected assets | Metafield = Require |
No users have to request any assets except selected formats | Metafield = Bypass |
No users have to request any assets except selected assets and selected formats | Metafield = Require |
Please be aware that this does not into consideration that there is the bypass role “Download_Approval_Bypass “ which, as previously stated, will disregard any configured download restrictions.