WEBVTT

1
00:00:09.858 --> 00:00:12.069
Hello and welcome to Zammad Academy!

2
00:00:12.137 --> 00:00:16.053
My name is Dusan and we will be showing
off a new feature in Zammad version 5.4,

3
00:00:16.070 --> 00:00:19.210
called “Expert Object Conditions”.

4
00:00:19.278 --> 00:00:21.574
Normally in the context of Zammad,
Object Conditions

5
00:00:21.574 --> 00:00:23.633
differ
depending on the function behind them.

6
00:00:23.633 --> 00:00:27.262
They are used as a way to customize
the rules behind many Zammad features,

7
00:00:27.381 --> 00:00:30.453
most notably the ticket overviews.

8
00:00:30.537 --> 00:00:34.471
While it was always possible to customize
Zammad features with high granularity,

9
00:00:34.640 --> 00:00:37.577
certain limitations were put in place
for the sake of simplicity.

10
00:00:38.657 --> 00:00:41.814
However, modern processes
don't always care for simple solutions,

11
00:00:41.814 --> 00:00:44.211
and it was needed to partially lift
some of the restrictions

12
00:00:44.211 --> 00:00:47.469
so the processes could be modelled
with ease.

13
00:00:47.554 --> 00:00:50.778
Without further ado, let's take a closer
look at the new expert mode,

14
00:00:50.778 --> 00:00:55.505
which allows you to create even more
powerful conditions in your Zammad system.

15
00:00:55.589 --> 00:00:59.218
We will be creating a much requested
workflow in Zammad: a single ticket

16
00:00:59.218 --> 00:01:02.038
overview showing all your tickets
currently ready for action.

17
00:01:03.236 --> 00:01:04.941
A ticket in Zammad is considered

18
00:01:04.941 --> 00:01:09.313
as ready for action
if it is in the “new” or “open” states.

19
00:01:09.381 --> 00:01:12.926
However, it's also possible to put
a ticket in the “pending reminder” state,

20
00:01:13.162 --> 00:01:15.087
with a target pending till time.

21
00:01:15.087 --> 00:01:19.324
Once this pending time is reached,
the ticket is also considered actionable.

22
00:01:19.408 --> 00:01:23.071
Let's try to combine these conditions
in a new overview, which we will aptly

23
00:01:23.071 --> 00:01:27.579
name “Tickets Ready for Action”.

24
00:01:27.663 --> 00:01:31.141
We will be allowing it for all users
with the “Agent” role.

25
00:01:31.225 --> 00:01:34.314
Next, we will add the first condition
for ticket “State” attribute,

26
00:01:34.314 --> 00:01:37.707
where we can filter for
tickets in “new” and “open” states.

27
00:01:37.792 --> 00:01:42.282
Then, we want to add a second condition
for tickets with “pending reminder” state.

28
00:01:42.350 --> 00:01:46.165
However, we see it's not possible
since we can have only one attribute

29
00:01:46.165 --> 00:01:47.701
of type “State”.

30
00:01:47.701 --> 00:01:50.756
Because we need a more complex condition,
we can first switch

31
00:01:50.756 --> 00:01:54.065
to “Expert Mode”
by toggling the switch below the box.

32
00:01:54.149 --> 00:01:56.428
Our existing conditions
are converted in place,

33
00:01:56.428 --> 00:01:57.593
and now we are allowed to add

34
00:01:57.593 --> 00:02:01.138
a second condition for tickets
with “pending reminder” state.

35
00:02:01.223 --> 00:02:04.548
Finally, a third condition filters
only for tickets with reached

36
00:02:04.548 --> 00:02:08.076
pending times: one minute in the past.

37
00:02:08.161 --> 00:02:11.942
If we would leave the conditions
as-is, no tickets will ever be matched.

38
00:02:12.297 --> 00:02:15.318
This is because the system expects
for all of the conditions to be true

39
00:02:15.318 --> 00:02:16.888
at the same time,
which is simply impossible.

40
00:02:16.888 --> 00:02:17.462
A ticket cannot be in the “new”
or “open” state

41
00:02:17.462 --> 00:02:18.053
and in the “pending
reminder” state as well.

42
00:02:18.053 --> 00:02:20.096
Therefore,
we now switch to using the “Match

43
00:02:20.096 --> 00:02:23.978
any (OR)” operator
between the top-level conditions.

44
00:02:24.063 --> 00:02:26.122
This will still not return
appropriate matches,

45
00:02:26.122 --> 00:02:29.887
because it will also include any tickets
with pending times far in the future,

46
00:02:29.971 --> 00:02:32.723
which are currently not requiring
any immediate actions.

47
00:02:34.259 --> 00:02:35.576
To solve this, we will first

48
00:02:35.576 --> 00:02:39.087
add a sub-group with the default “Match
all (AND)” operator.

49
00:02:39.171 --> 00:02:42.564
Then, we will move the second
and third condition to the new sub-group

50
00:02:42.564 --> 00:02:46.599
with simple drag and drop gesture.

51
00:02:46.683 --> 00:02:49.520
Conditions for “pending reminder” state
and pending till time

52
00:02:49.520 --> 00:02:53.942
have to be grouped together,
so they can match at the same time.

53
00:02:54.027 --> 00:02:57.656
Finally, we are getting the right results
in the preview, because the conditions

54
00:02:57.656 --> 00:03:01.252
will be matched within proper branches.

55
00:03:01.319 --> 00:03:03.717
All tickets are now selected,
which are having the state

56
00:03:03.717 --> 00:03:07.819
“new” and “open” or the state
“pending reminder”, always in combination

57
00:03:07.819 --> 00:03:11.971
with the condition
that the reminder was already reached.

58
00:03:12.056 --> 00:03:15.601
Once we save the new overview,
it will immediately be available for use.

59
00:03:15.803 --> 00:03:19.551
By switching to it, we can once again
confirm that the ticket subset is correct.

60
00:03:27.384 --> 00:03:30.287
The “Expert Object Conditions”
feature is available since Zammad 5.4.

61
00:03:30.287 --> 00:03:33.174
However, in Zammad hosted environment,
it is

62
00:03:33.174 --> 00:03:36.635
currently limited to “Plus” package
customers only.

63
00:03:36.719 --> 00:03:40.787
Supported screens include: “Overviews”,
“SLAs”, “Triggers”, “Scheduler”,

64
00:03:40.787 --> 00:03:56.791
“Report Profiles” and “Automatic
ticket assignment”.

65
00:03:56.875 --> 00:03:58.428
We hope this demo has been helpful,

66
00:03:58.428 --> 00:04:00.690
and we look forward to see your complex
creations.

67
00:04:00.707 --> 00:04:03.509
Feel free to share your recipes
in Zammad online community!