How do they work?

Find a description of the different parts of the core workflows below.

Object

Choose the object context you want to run the workflow in. This will decide on your available attributes and actions. Ticket objects also have access to the ticket customer.

Context

Choose in which situation the workflow is applied. Contexts can be combined to avoid duplicate workflows.

Creation mask

If selected, your conditions and actions will affect all applicable creation masks.

Edit mask

If selected, your conditions and actions will affect all applicable edit masks.

Conditions

Zammad differentiates between selected and saved conditions. These can be combined wherever needed. You can find a description of the condition operators for core workflows in Core Workflow Condition Operators.

Warning

⚠️ Restrict workflows to specific roles if needed!

By default and unless configured in conditions, workflow rules are executed for all roles. This also affects your customers!

Selected Conditions

These conditions are based on form values and match if an appropriate selection is made (e.g. choosing another group in the ticket without saving). This applies for drafts (active selection) and currently saved values.

Saved Conditions

These conditions only match if the selected values are stored in the database. It ignores the current value or selection of the field, as long as the changes are not saved (e.g. performing field operations for an existing ticket, which is viewed/opened by an agent).

Note

Keep in mind that the value has to be available in the situation where you need it. Otherwise the condition won’t match.

Example: you can’t perform any actions with saved condition on a ticket in creation, because there are no saved values at that time.

Action

Define which actions should get applied to the relevant fields. The possible actions depend on the object type. However, usually you can at least change the visibility and whether the field is mandatory.

Be aware that actions are not available for related context. Example: Let’s assume you are working in the ticket context. While you can have customer conditions, you can’t adjust objects with actions in that scope. That’s because this wouldn’t have any impact on the ticket dialog. Of course all ticket attributes (state, owner, …) are available.

Available Operators

The availability of operators depends on the object type and scope.

Hint

Please note that actions may or may not restrict API based access to attributes. We’re displaying the following icons for your overview to understand these limits better:

This icon indicates the action affects the API.

This icon indicates the action only affects the web interface.

show

Display the chosen field. Allows setting of values.

hide

Hide the chosen field. However, it technically still allows setting the field.

Please note that the field is not gone and still contains an existing value (if set)! Consider remove instead, if you want this field to be gone.

remove

Entirely removes the field. The field value will not be evaluated.

set mandatory

Sets the field to mandatory.

set optional

Sets the field to optional.

add option

Allows adding options to tree selects or selects.

You have to use the “remove option” before performing this action. It allows you to use existing configured values.

remove option

Allows removing options from tree selects or selects. It allows you to use existing configured values.

set fixed to

Reduces the available options by your selection.

This reduces your workflows in terms of add option and remove option.

fill in

Allows filling in of string and integer fields with your values.

fill in empty

Allows filling in of string and integer fields with your values if the field is empty.

select

Select a specific value within a select, tree select or boolean field.

auto select

Helps users with tree select and select fields:

If the field has only one option available for selection and no value yet, the value will be automatically set.

This option only works if you have one value and doesn’t work if there is more than one option available.

set readonly

Allows you to display an attribute as read only (which means no changes are possible).

unset readonly

In case a workflow set the field in question to read only, you can undo this with option above.

Stop after match

Decide if other workflows are executed after the current one.

If set to no (default), further workflows will be executed if they match the condition. In this case, it is possible that your actions from the current workflow can be overwritten by another workflow. If set to yes, no further workflows will be executed after the current one.

Priority

You can define the sequence of execution of the workflows by settings a numeric value. The execution runs in ascending order. That means lower values (e.g. 100) are executed before higher ones (e.g. 999).

The default value is 500.