How do they work?

Core Workflows are executed according to their priority. If two workflows have the same priority, they are executed in alphabetical order based on their name.

Because of the way Core Workflows work, all changes to attributes are checked with the application server - please see Limitations for possible issues.

Below we’re talking about settings that are important and not self-explanatory.

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.

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

Which actions should we run on 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.

Please also have a look at our Limitations to be safe from surprises.

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

Here you can 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 worflows will be executed after the current one.

Priority

You can define the sequence, in which the workflows are executed. The default value is 500.

The workflows are executed in ascending order by their priority. That means lower values (e.g. 100) are executed before higher ones (e.g. 999).