Roles
For the roles required to configure workflows and automations, please refer to: DC 5.5 Roles.
Asset approval workflow covers the first steps in an asset life cycle.
An example of a correctly configured approval flow presented here consists of three stages. In the first stage, the administrator makes a decision on which event should trigger an approval workflow. This is done with the help of an automation. The second stage is the actual approval workflow. Here, appropriate users are assigned to tasks complimentary to the approval (for example, filling out metadata) and to the actual task of either approval or rejecting assets. In the last stage of the process, another automation is configured to mark assets as approved or rejected in a way accepted by the organization.
The following elements are required for a functional approval process:
An automation containing a trigger and the action “Initiate Business Workflow”
A workflow with the minimum of three stages: a pending stage, an approved stage and a rejected stage.
All other elements are optional, though some might be heavily recommended, as it will indicated in the detailed descriptions of the stages below.
Part 1: Automation
The approval process is started by setting up a trigger that initiates a previously configured approval workflow.
In this example the trigger is uploading a new asset in the Media Manager. Two actions follow once the trigger is initiated: an previously configured approval workflow is started and the asset status of the newly uploaded assets is changed to “creative”.
Configuration:
Step | Configuration | Explanation |
---|---|---|
Location State Changed | New location state: Online | One or more assets are uploaded to the system. |
Initiate Business Workflow | Workflow name: select the correct approval workflow from the dropdown list Transition: select the first transition in the workflow Items: @sourceEntityItem Owner Member Id: @sourceMemberId Task name: (optional) Instance Id: (optional) | An approval workflow is initiated, which means that the tasks related to the workflow will now be distributed to the correct users. |
Set ComboValue Metafield | Meta Field: Status (guid) New Value: select the new status from the dropdown list Asset Item Id: @sourceAssetItemId | Asset status of the asset(s) is changed to “creative”. |
Part 2: Workflow
The second stage of the approval process is when the actual creative work and interactions between the users happen.
In the most basic form, the workflow should have a pending stage, an approved stage and a rejected stage. In this example, an additional stage was added for providing metadata for asset, before it can be approved. In the workflow, a task for filling out the required metadata is assigned to a correct user, and then another task is assigned to a user responsible for the approval decision. If asset(s) is rejected, it is also possible to create a loop to an earlier stage, so that eventual mistakes can be corrected rather than starting the whole process from the beginning (not included in this example).
Configuration:
Step | Configuration | Explanation |
---|---|---|
“Initiate” transition | Name: selected by the user Transition type: Manual Unique ID: selected by the user Description: selected by the user (optional) | This is the first transition of the workflow, triggered by the previously explained automation. The unique ID should be remembered as it needs to be provided in the “Initiate Business Workflow” step of that automation. The transition is manual, because it is initiated by a deliberate action from a user - in this case, an upload of new asset(s). |
“Awaiting metadata” 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: selected from the menu of all existing metadata fields Stage owner: Stage Assignment Behavior - 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. The metadata fields in this stage will be displayed in the task details. In this case, the stage owner is the instance owner, which means that the task assigned to the same user who uploaded the asset(s). The label will be displayed on the task. |
“Fill metadata” transition | Name: selected by the user Transition type: Automatic Unique ID: selected by the user Priority: relevant only, if multiple transitions happen at the same time, otherwise: 0 Description: selected by the user (optional) Constraints: metadata constraints and execution condition constraint | Automatic transition means that the workflow will be transitioned to the next stage, when the constraints are fulfilled. In this example it means that that filling out the relevant metadata will complete the task, whether this is done from the task dialog, or directly from the metadata editor. Constraints are the conditions for fulfilling the task. Here:
|
“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: Stage Assignment Behavior - Assign to a group 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 a user group. It means that any user belonging to that group can transition the task. i.e. approve or reject the asset(s). 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: execution condition | 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: execution condition | 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. |
Part 3: Automation
The last part of the approval process handles about what happens to the asset(s) which were approved or rejected.
In this example, the approved asset(s) are moved to public access, the lock is removed and the asset status is changed to “approved”.
Configuration:
Step | Configuration | Explanation |
---|---|---|
Business Workflow Stage Entered | Workflow: select the correct approval workflow from the dropdown list Stage Name: select the unique Id of the correct stage | This step identifies a specific stage in a specific workflow, which triggers this automation. |
ForEach | Variable: @sourceItemIds As: @itemid | This step means that a set of actions, specified in the inner flow of the step, is undertaken for each asset, which is the approval task pertains. |
Move Asset To Folder (in: ForEach) | Asset Item Id: @itemid Folder: Public access | The approved asset(s) is (are) moved to the public access in the DAM Center. |
Set Bit Metafield (in: ForEach) | Meta Field: Is Public New Value: true Asset Item Id: @iemid Use Versioned Metadata: false | The lock is removed from the approved asset(s). |
Set ComboValue Metafield (in: ForEach) | Meta Field: Status (guid) New Value: select the new status from the dropdown list Asset Item Id: @sourceAssetItemId | Asset status of the asset(s) is changed to “approved”. |