How do they work?¶
Core Workflows are evaluated by priority. If 2 workflows have the same priority by alphabetical order by name. Workflows are evaluated in alphabetical order, by name.
Because of the way Core Workflows works all changes to attributes are checked with the application server – please see Limitations for possible issues.
Below we’re talking about settings that have an impact and are not self-explanatory.
Choose the object context you want to run the workflow in. This will decide on your available conditions and actions.
You will be able to use objects that are in relation to your selection in your conditions.
Choose in which situation the workflow is applied. Contexts can be combined to reduce workflows.
- Creation mask
Once selected your conditions and actions will affect all applicable creation masks.
- Edit mask
Once selected your conditions and actions will affect all applicable edit masks.
Zammad decides in between selected and saved conditions. These can be combined wherever needed.
🤓 Combining conditions allows “OR”-selections
However, note that each condition type counts as and selector and can’t overrule the other condition type.
Every attribute can be used once per condition type.
⚠ Restrict on role basis if needed ⚠
By default, unless configured in conditions, workflow rules are evaluated for all roles. This also affects your customers! 🙀
- Selected Conditions
These conditions only match if they’re active in selection. This applies for drafts (active selection) and currently saved values.
- Saved Conditions
These conditions only apply if they’re saved within the database regardless of the current value or selection of the field.
Keep in mind that the value has to be available in the situation where you need it. Otherwise the condition won’t match.
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.
🚧 Actions are not available for relations
Let’s say you’re working in 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 dialogue. 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.
🧐 Actions can cause confusion
Display the field in question. Allows setting of values.
Hide the field in question however, technically still allows setting the field.
The field is not gone and still contains any value it provides! You may want to consider remove instead.
Entirely removes the field. The field value will no get 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.
This requires options to be hidden beforehand (remove option). It allows to use existing configured values.
- remove option
Allows removing options from tree selects or selects.
It allows to use existing configured values.
- set fixed to
Reduces the available options by your selection.
This may indirectly reduce your workflows in terms of add option and remove option. 🤓
- fill in
Allows population of string and integer fields with your value.
- fill in empty
Allows population of string and integer fields with your value if the field is empty.
Select a specific value within a select, tree select or boolean fields.
- auto select
- Helps the user on tree selects and select fields:If the field has one option to select only and has no value yet, the value is automatically set.
This option only works if you have one value and acts passively with more options.
- set readonly
Allows you to display an attribute as read only.
- unset readonly
In case a workflow set the field in question to read only, you can undo this with above option.
Stop after match¶
Stop evaluation of other, following workflows that would match otherwise.
You decide at which point your workflow is evaluated. Priorities are sorted descending – this means that a workflow matching can stop matching in specific situations.