DC 5.3.0 4.10 Automation Workflows

Introduction

Automation workflows allow administrators to make the Digizuite™ DAM Center do things automatically - triggered as other things happen in the system. 
Automation workflows replace the existing ItemWatcher workflows (And anything else that depends on digimonitor).

To interact with an automation workflows, a Media Manager with at least version 5.2.0 is required. 

Workflow construction

Automation workflows are built with "steps". A step can be either an "action", a "trigger", a "filter", or a "foreach loop". 

Triggers

A workflow is always started by a trigger. A trigger is a special kind of step that listens for events in the overall system, such as an asset being uploaded, or metadata changing.

Actions

To actually do something your workflow needs actions. Actions all do one single thing, such as: updating a metadata field, or, triggering an asset publish event. 

Filters

To prevent the workflow from firing all actions without any logic, a filter must be used.

Filters check that a condition in the Digizuite is met, e.g. that the asset type of an asset is an image, or that a member has a certain role.

If the condition is not met, the subsequent filters and action below it will not be executed.

Foreach loops

Lastly, there are loops, which is a special construct that allows for repeating a certain set of steps, over a set of data, executing the steps for each data point in the set. (This is very similar to how foreach loops are in other programming languages)

Creating a new workflow

First of all, you need the proper roles to be able to access the workflow menu point

To create a new workflow, please do the following:

1. Press "Workflow management" in upper-middle of the page

2. Next click on "Workflows"

Open

       3. Select "Add new" (Or, for more advanced users, you may choose "Add existing")

Open

       4. A menu will open to the left.

       5. In this menu, press "insert" on the type of trigger you want.

What each trigger does is documented at the bottom of this document. 

Using the visual editor

Once a workflow has been opened in the editor, a flowchart-like view is shown.

If you selected "Add new" - only the trigger you chose will be shown.

If you selected "Add existing", the workflow you inserted will, of course, be shown instead.

Adding a new step

To add a new step to the workflow, drag from the colored circle on the bottom of an existing step.

When you start dragging, a new node placeholder will appear. Drag your cursor onto this placeholder, and let go. 

Open

When you let go, a pane will open on the left, where the step to insert must be selected. You can pick all step types than triggers.

The step should now be inserted where the placeholder was.

For the step to be valid, you need to fill out the step's parameters.

This is done by pressing the "more" button on the step - and selecting "edit".

A dialog will now open to the right. 

Open

In this dialog fill out the parameters, and select "apply" when done. 

Workflow text syntax

Behind the flowchart-like UI, code is being generated by the actions you perform with the steps.

This code can be accessed by going pressing the "Text mode" button:

Open

The code could, for example, look like the following:

Sample

Each step is identified first by a keyword "trigger", "filter", "action", or "foreach", and then followed by a name in quotes. This name must be unique in the workflow: trigger "Asset Uploaded"

The parameters for each step are saved in between the curly brackets: {}

Each parameter is identified by a key, an equal (=) sign, and then the value in quotes: upload_computer = "Digizuite Media Manager profile"
It is possible to have a set of values (aka. lists, arrays), by putting the values inside square brackets "[ ]", as seen from the "resolves" parameter: resolves = ["Move to User Profile Images", "Move to channel user profile folder"] 

A more formal version of the format can be seen in the following railroad diagram:

Open

Most of the parameters for each step are dynamically generated. However, 3 parameters almost always appear (depending on the keyword used for the step).

"type" is required on all steps. It refers to the action or filter that should be run. In the example above "Asset Created Trigger" is the type, which means that it will trigger when an asset is created. The specified types available, are documented at the bottom of this document. 

Next we have "resolves", as seen in the above example. "resolves" is specified on all triggers, and refers to the last step in a chain of steps, that should be executed. 

Lastly, we have "needs", which is used on actions and filters. It refers to steps that should be executed before the step with the "needs"; thus creating a chain of dependencies (This must run before that).

Foreach loops

Foreach loops are a bit special since they allow for the repeated execution of a set (chain) of steps within a workflow. To implement a foreach loop, you have to specify 5 parameters (The can, of course, be done from the visual, flowchart-like, UI):

• "type", which should be set to "ForEach".

• "resolves", which should be the last step in the chain of steps to execute. 

• "needs", which specifies all steps that must have run before entering the foreach loop. 

• "variable", which specifies which variable to iterate over. This accepts both one ("test 1") and many values (["test 1", "test 2", "test 3"])

• "as", specifies what "variable" should be available as, in each iteration of the foreach loop. I.e. the current variable in the list to interact with.

Variables

Workflows use variables in order to pass data between different steps. Variables are identified by starting with an at-sign (@), for example, "@sourceAssetItemId". 

Triggers usually emit some variables, such as; the asset that triggered the workflow.

To pass a variable to an action or filter, just write the variable name, such as "@sourceAssetItemId".

If you try to use a variable before it's ready, you will get an error when you run the workflow. 

Some actions have "exported" variables. This means that rather than reading a variable before it executes, it sets the variable after it has executed. 

Tips and tricks

Required metadata fields (logic gate operators)

AND operator

"filter" steps below each other.

If two or more metadata fields are required before a given step should execute, you should position the filters below each other (i.e. make the workflow linear rather than branching).

Open

OR operator

"filter" steps beside each other.

If you have multiple fields, but only one of them is required, you should position the filters beside each other.

Open

Available steps

This documentation is auto-generated from the source, hence it's very unlikely to contain mistakes.

Some additional manual documentation might be provided below. 

Available triggers

Available actions