MM5.9 Workflows
- Mathias Mattson (MHM)
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 |
|---|---|
Top area of the modal | This is the name of the transition. |
Transition type |
|
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 |
|---|---|
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:
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:
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 |
|---|---|
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 |
|---|---|---|
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.