Learn by Example¶

This page showcases some examples for core workflows. To learn about core workflows in detail, first go to How do they work?.

Basics¶

All core workflow examples below are configured in the same system. Compared to a fresh installation of Zammad, the system has some additional groups and some custom object attributes you can find in the respective examples. See these examples as inspiration and adapt the workflows to your processes.

Group Based Fields¶

Often, different teams (like sales, support, or 2nd level) need slightly different workflows to handle tickets effectively. Group-based workflows allow you to customize the ticket experience by defining the fields displayed, the required input and the available options based on the group assigned to the ticket.

Problem/scenario

When a ticket is created in or moved to the 2nd Level group, the category field must be limited, some fields have to be shown and specific fields are mandatory to have all relevant information for the 2nd level support present in the ticket.

Workflow configuration

Area	Configuration	Note
Object	Ticket
Context	Creation mask Edit mask
Selected conditions	Group is `2nd Level`
Saved conditions		Not used because the UI has to change immediately when the group is set to 2nd Level.
Action	Category show Category set fixed to `2nd Level` (and all sub categories) Operating System and Software used show Operating System and Software used set mandatory

Configuration in UI

Sample workflow that shows specific values and fields for 2nd level

Approval Process¶

In many organizations, an approval is required to initiate subsequent processes. This approval is usually limited to a specific group of people to ensure that all requirements for the subsequent process are fulfilled.

Problem/scenario

The approval of a customer issue can only be done by users with the role Approval Person. As long as this approval has not been done, the value must be set fixed to no, unless the approval person views the ticket.

Based on the approval state, additional automation processes can be established (e.g. a trigger to raise the priority or assign a specific agent).

Workflow configuration

Area	Configuration	Note
Object	Ticket
Context	Creation mask Edit mask
Selected conditions	Role is not `Approval Person`	Checks if role is not `Approval Person` for unsaved changes in the ticket.
Saved conditions	Approved is not `yes`	Checks if the approval is not yet set to `yes`.
Action	Approved set fixed to `no`	Prevents changes when above conditions are met.

Configuration in UI

Sample workflow that restricts an approval attribute to specific roles

Enforcing Ticket Categorization¶

To have convincing numbers for your statistic, it can be a good idea to enforce certain attributes to be populated before the ticket can be closed.

Problem/scenario

The Category field must be set to mandatory if an agent wants to set the states closed or pending close to enforce categorization.

Workflow configuration

Area	Configuration	Note
Object	Ticket
Context	Creation mask Edit mask
Selected conditions	State is `closed` or `pending close`	Selected condition because it has to be checked before changes are saved.
Action	Category set mandatory

Configuration in UI

Sample workflow that sets fields to mandatory on specific states

Ticket Handover Process¶

A handover from one agent to another might require more than just a change of the owner. Depending on the issue or process, it can be very helpful that the original agent leaves a small note so the new agent knows immediately what’s the reason for the handover and where to start.

Problem/scenario

Agents must write a small comment when they want to change the ticket owner. There is a custom ticket attribute called Handover where a text can be inserted. This field is hidden by default (Workflow 1) and only shows up when the owner changes. Additionally, it must be set to mandatory in such a case (Workflow 2).

Because the field is hidden after saving the change of the ticket owner, the text of the field has to be written to the ticket as an article by a trigger. Otherwise, the new agent would not see it at all.

Workflow configuration

This workflow hides the field in general. Please note the lower priority which tells Zammad to execute this workflow first.

Area	Configuration	Note
Object	Ticket
Context	Creation mask Edit mask
Selected conditions		No condition needed, because it should always be hidden.
Saved conditions		No condition needed, because it should always be hidden.
Action	Handover hide

This workflow shows the field and sets it as mandatory when another ticket owner is selected. This workflow has the default priority so it runs after Workflow 1.

Area	Configuration	Note
Object	Ticket
Context	Creation mask Edit mask
Selected conditions	Owner is modified	Selected condition because it has to be checked before changes are saved.
Saved conditions
Action	Handover show Handover set mandatory

As mentioned above, the content of the field has to be written as a ticket article by a trigger. An example configuration of such a trigger could look like this:

Condition: Handover has changed
Action: Article > Note with variable #{ticket.handover} in body

Configuration in UI

Hiding the handover field in core workflows

As a result, the ticket includes an article of the type note which includes the predefined text and the handover comment.