MM5.8 Setting up approval workflow

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

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

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:

  • Metadata constraints are selected from the menu of all available metadata fields. These are the metadata that need to be filled out, before the asset(s) can be approved.

  • “Assignee can transition” constraint gives the assignee the rights to transition the task, even if the user does not have the role allowing this.

“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:

  • “Allow the assignee to transition” means that only the user(s) assigned to this task can either approve or reject the asset publication.

“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:

  • “Allow the assignee to transition” means that only the user(s) assigned to this task can either approve or reject the asset publication.

“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

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”.