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.
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.
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.
Zammad differentiates between selected and saved conditions. These can be combined wherever needed.
⚠️ 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).
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.
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.
The availability of operators depends on the object type and scope.
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:
Display the chosen field. Allows setting of values.
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.
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 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
You can define the sequence, in which the workflows are executed. The default
The workflows are executed in ascending order by their priority. That means
lower values (e.g.
100) are executed before higher ones (e.g.