MM5.7 Workflows

General information

Unlike the automations described in the previous section of the User Guide, used for automating repetitive work, the purpose of workflows is to support collaboration between users, by standardizing business processes. Therefore, workflows require user interaction in order to advance.

An example of such a standardized business process can be found below. The screenshots show a basic request workflow, where the request could concern, for example, the download of an asset, the approval of a newly self-signed up user, or the publishing of an asset, both in flow mode and in text mode.

Flow mode (a graphic representation of the workflow):

Text mode (the code behind the workflow):

To access workflows, press the Settings button in the top right corner, and enter Workflows.

From here youā€™ll get access to edit and delete existing workflows, or creating new ones.

Creating workflows

You have three options when creating workflows:

  • Create workflow from DSL

  • Duplicating a workflow (oftentimes referred to as ā€œCreate from templateā€œ)

  • Create new workflow

These are to be access via Settings ā†’ Workflows.

Creating workflow from DSL code

Our documentation shows off often-used workflows, like the approval workflow shown above. Simply find the code (also known as the DSL or Domain Specific Language) in the documentation, copy it using your computerā€™s clipboard and access the Settings ā†’ Workflows area. Press Create ā†’ Create workflow from DSL, paste in the code/DSL and hit the Create button.

Duplicating an existing workflow

To duplicate a workflow, all you have to do, is to press the Create button inside of Settings ā†’ Workflows, and selecting the workflow you wish to copy in the Choose a template combobox. Hit OK, and youā€™re done.

Creating new workflow

Selecting Create new workflow will prompt the modal shown below. In this, enter the workflow name, and hit OK.

Editing workflows

Regardless of the creating method you chose, you can now start editing the workflowā€™s stages, transitions etc.

In case youā€™ve created a new workflow, you will need to create a first stage. Clicking Add first stage button. The following stages are added by clicking the dot at the bottom of stage and dragging the line to the next stage, while pressing down with the cursor.

The user is now ready to start editing the transitions and stages.

General workflow settings

In order to access a workflowā€™s settings, the user needs to click on the three dots next to the workflow name and select Edit.

This will open a panel on the right, where the user can do the following:

  • Change the workflowā€™s name

  • Select whether the workflow should be limited to one task per item (enabling this, will ensure that there can be only one active instance of the workflow pr. asset).

Editing transitions

In order to edit a transition, the user needs to click on a the transition arrow.

This will prompt the appearance of a transition modal, where the user has the ability to edit or delete the transition

The following editing options are available for transitions:

Option

Description

Option

Description

Top area of the modal

This is the name of the transition.

Transition type

  • Automatic transition happens when the conditions specified by the constraints are fulfilled.

  • Manual transition is the default option. It means that an assigned user needs to manually transition to the next stage by clicking on the action button in a resulting task and selecting one of the available options.

  • Timed transition happens after a specific period of time.

Unique ID

Can be any value consisting of letter and numbers. It needs to be unique only within the same workflow. It is used to identify a correct transition when setting up automations dependent on existing workflows.

Priority

This is available for automatic transitions only.

If there are are multiple transitions triggered automatically at the same time, you can decide which transition wins out. This ensures the user that their system is always in a known state, as race conditions arenā€™t occuring.

Postpone until

This is available for timed transitions only.

If selected, the automatic execution of the transition is postponed by a set period of time (Set duration) or until the day specified in a Date Input Constraint within the same workflow (Pick key).

Description

This is an optional field meant to provide an explanation of what is supposed to happen in a particular transition. It is especially useful, if there are multiple users working with the same workflow.

Constraints

The user can set up conditions that need to be met for the transition to occur.

Tooltip: If the user is in doubt about what kind of information should be filled out in specific fields, hovering over a question mark next to it will prompt an explanation.

Constraints are the required conditions that need to be met in order to transition to a stage. There are four types of constraints available in the system:

  • Input constraints

  • Metadata constraints

  • Upload constraints

  • Execution conditions

In order to add a new constraint, the user needs to navigate to the tab Constraints and then click on the button Add new constraint.

The next step is to select the correct option from the list of available constraint types.

Constraint type

Description

Constraint type

Description

Input constraints

This type of constraint can usually be found in download requests. Here, the user is asked for different types of input.

The following constraints are available:

  • Date Input Constraint - the user who makes a request will have to choose a date from a calendar

  • String Input Constraint - the user who makes a request will have to fill in a text field. Can be rendered as both a string and a note field.

  • Combo Input Constraint - the user who makes a request will have to choose from a combo box you define.

This is an example of this type of constraint:

Metadata constraints

This type of constraint gives the workflow administrator a great flexibility in terms of constraints as it allows to point to and interact with the metadata fields available in the customerā€™s Media Manager. In this type of constraint the metadata fieldā€™s content must match the condition.

This is an example of a metadata constraint:

It is very important that the System user has minimum the read rights to the metadata field. Otherwise, it will not instantiate correctly and it will throw an error during the instantiation. It is preferable that the System user has both read and write rights to all the metadata fields, either as an individual user or through a group.

Upload constraints

The user who makes a download request will have to attach a file in the from specified by workflows administrator. This could be e.g. a consent form.

The upload constraint will be presented the same as any other input constraint, i.e. the functionality is the exact same as the other input constraints.

This is an example of an upload constraint:

Execution condition

This type of constraint is related to who can execute the transition. The following constraints are possible:

  • Any user can transition

  • Allow the assignee to transition

  • Allow the workflow creator to transition

  • Allow a specific user or group to transition

This is an example of an execution condition constraint:

Each constraint item has two icons in the upper right corner: one for the available actions regarding the constraint, and the other for re-ordering the constraint.

Additionally, the user can click on the top area of a constraint box in order to collapse or expand it. This is how collapsed constraints look:

Editing stages

The user can edit a stage by simply clicking on it. The editing area will open on the right side of the screen. This is how the stage editor looks:

The following editing options are available for stages:

Option

Description

Option

Description

Top area of the modal

This is the name of the transition.

Unique ID

Any value consisting of letter and numbers. It needs to be unique only within the same workflow. It is used to identify a correct stage when setting up automations dependent on existing workflows + if you delete a stage, this name will be visible when you transition all the tasks that is in this stage at the time of deletion.

Description

This is an optional field meant to provide the explanation of a particular stage. It will be shown in the task list and can indicate what an assigned user is supposed to do in this specific stage.

Mark as completed

Enable this on end stages. It is solely used to filter away tasks that are done in the task list. It has no other use/repercussions than this.

Relevant metadata field

The content of the metafields you set here, will be shown in tasks' details views.

Stage Owner

This decides which user or group is to be automatically assigned once this stage is entered.

This is explained in more detail in an upcoming paragraph.

Labels

It is possible to select a label which will visually represent the stage, both in the editor and the task list.

It is possible to choose one of the predefined labels or create a custom one.

Assigning a stage owner

The stage owner is the user or group who gets assigned a particular stage in a workflow.

When assigned on a stage, the task will appear in their task list. They'll need to perform an action for the task to progress, like, for example, approving or denying a download request.

There are 6 different types of automatic assignment behavior:

Scenario

Configuration

Explanation

Scenario

Configuration

Explanation

There is no stage owner.

Set Stage Assignment Behavior to ā€œUnassignedā€.

This option should be used for the stages where no users or groups should be assigned.

An example of this could be that your task has reached an end state, e.g. a download request has been approved. No further action is needed here, and thus no one should be assigned.

The stage owner is a user.

Set Stage Assignment Behavior to ā€œAssign to a userā€. In the new field below select the stage owner from the provided list.

This option should be used for stages that should be assigned to a specific user. All the available users are presented in the drop-down list.

The stage owner is a group.

Set Stage Assignment Behavior to ā€œAssign to a groupā€. In the new field below select the stage owner from the provided list.

This option should be used for stages that should be assigned to a specific group. All the available groups are presented in the drop-down list.

The stage owner is the instance owner.

Set Stage Assignment Behavior to ā€œAssign to the instance ownerā€.

Ā 

This option should be selected, if the stage needs to be assigned to the user who initiated the event.

Ā 

An example of this is, that you have an asset approval workflow, where the uploading user needs to fill in some metadata or input constraints before the approver is assigned.

As uploading cannot be ā€œconstrainedā€œ, the first stage you create must be assigned to the instance owner, to ensure that (s)he fulfills the metadata/input constraints before sending it onwards.

Current user or group remains as the stage owner.

Set Stage Assignment Behavior to ā€œKeep current user or groupā€.

Use this if you wish to retain the assignment set in the previous stage(s).

The stage owner is assigned by whatā€™s set in a metafield.

Set Assign from Metafield to the correct MasterItemReference type metadata field from the list.

Ā 

This option allows for more flexibility when assigning, as this gives the ability to assign users and groups based on a value set in a metafield.

A use case could be a situation in which each asset has an owner who is responsible for what happens with this particular asset (like a photographer). Having the ability to link an asset with a user or group, allows for easy ownership assignment.

Please note that ā€œassign from metafieldā€ only works, when there is only one asset in the task. If the ā€œassign from metafieldā€ fails due to a too high number of assets in a task - or because the indicated metadata field is empty - the automatic stage assignment will act as a fallback. This is why the user needs to configure both options.

Saving a workflow

Once the workflow is fully defined, the user should click the Save button in the upper right corner of the workflow editing area.

Tasks

Tasks can be accessed by clicking the Tasks icon on the right side of the top bar.

The tasks are available to two categories of users:

  • Workflow administrators can access the tasks assigned to them in order to see all active and completed tasks as well as take actions.

  • End users will interact with the system in a different way. Typically, theyā€™ll make requests, like for requesting download, upload, or sign up. As these users typically do not have access to the task list, only certain tasksā€™ statuses are visible for them, download request being the only one.

Each task is defined by the workflow name, status and the created time and and date. The tasks can be sorted by type and creation date. Itā€™s not necessary to reload the page to see the most current task list. The user can simply hit the refresh button in the upper right corner.

Tasks can be shown in a list and a card form:

In order to simplify the process of working with tasks, the list is paginated and the user can select how many tasks should be visible on one page (between 12 and 200). If infinite scroll is enabled for the system, the tasks will also load in infinite scroll.

The users have the following filters at their disposal, when working with tasks:

  • Task name (freetext search)

  • Quick filters

  • Status

  • Workflows

  • Assets

  • Created by (user)

  • Created by group

  • Assignee (user)

  • Assigned group

Task details are accessible in the right-side panel after clicking on it once.

In the top of the newly-opened panel there are basic information concerning the task (the name of the workflow and its current status), the option to delete the task - as well as a button that opens a drop down with available actions. In the lower part of the panel there are several tabs with additional content that the user can switch between:

  • Summary - Who created the task, the date of creation, promoted input constraints as well as a short summary of assets, attachments, and comments

  • Details - Information concerning all input constraints, apart from attachments

  • Assets - All assets the task concerns in either box view or list view

  • Comments - Used for the direct communication between users involved with the task - also for high-level users who have access to other users' tasks to communicate.

  • Attachments - Attached files related to upload constraints

  • Metadata - Metadata fields relevant to the task are displayed

The tabs that do not contain any information are greyed out and cannot be accessed.

Transitioning the task

As described at the beginning of the page, some tasks are transitioned automatically upon clearing the required constraints. The most common type of transition, however, is the manual transition. In this case, the user assigned to the task needs to take an action, before the workflow can transition to the next stage.

The list of actions available for a particular tasks is shown upon clicking the Action button. The button is located in two different places:

  • in the task list view, in the last column

  • in the task detail view, in the upper right corner of the modal.

If there are no constraints attached to the selected action, the transition will be successful instantly.

If there are constraints attached to the action, the user needs to perform additional tasks, before the transition can occur. The task depends on the type of the constraint:

  • In case of input constraints, the user needs to fill in additional information in the form of text, date or selecting an option from the provided list

  • In case of upload constraint, the user needs to upload a file in a required format

  • In case of metadata constraints, the user needs to make sure that the provided metadata fields are filled in according to the requirements.

Multi-transition of tasks

It is possible to perform the transition of multiple tasks at the same time. However, the tasks must meet the following conditions:

  • The tasks must be in the same stage - in the same workflow.

  • The user must have the ability to transition each task individually.

To multi-transition tasks, first select the relevant tasks either by clicking the empty checkmarks on the left side of the task, or via ā€œdrag and dropā€ method in the card view.

If the tasks fail to meet any of the conditions, the multi-action button at the top of the task list will be inactive.

If all the conditions are met, clicking the newly activated multi-action button will result in the appearance of a new dialog, where the user will be guided through the transition process.

Ā