first of all: Yes, you may and can use more than 20 overviews.
However, this might affect Zammad in a negative way in terms of performance.
Please note that if you have 8 departments / groups which are logically and by permission divided (so agent from department A can’t see tickets from department B to H), you wouldn’t need to create dozens of overviews.
By the way, because you want to display closed tickets:
Please do yourself and your agents an favor:
ensure to only show the last x days of tickets with closed state
make sure that your overview doesn’t try to display more than 2100 objects
Especially overviews that show “all closed tickets” are known to be a performance killer “for nothing”. Zammad limits overviews to 2100 tickets as of now. This is for performance reasons.
By saying affect performance what you mean exactly by performance (response time database)? and if I give more CPU and memory to my server could I solve this problem?
ensure to only show the last x days of tickets with closed state
make sure that your overview doesn’t try to display more than 2100 objects
--------> How I could do that? using macro?
Okay firstly: You can’t solve everything with more ressources.
At some point your biggest issue will be a single core because if a process runs at 100% core capacity, you can’t magically get another 50% on that core. So adding more power just works to a specific extend.
Performance issues can have several reasons, especially when talking about overviews we’re talking about the following effects (mostly, but not exclusively):
high number of delayed jobs causing
search indexing to take a lot longer than usual
delays with email sendout (in every expect)
delays during fetching mails
slow overview refreshing (up to the point they don’t seem to refresh at all)
slow responses from the UI (this most of the times is a combination issue coming from above)
We improved Zammad a lot on terms of overviews, however, overviews are generated for every active agent session individually. This means if you have 20 active agent sessions each seeing 20 overviews, Zammad generates 400 overviews per run. The more complex the overviews get and the more they have to provide, the more time this process takes. This can end in Zammad taking minutes to generate those overviews which causes delays on other essential parts.
You see, those problems have a lot of layers and may have great impact on other core functions as well. In the end it’s very hard to tell a specific number to someone, because every system behaves absolutely different. From my time at Zammad I learned that a reasonable limit lives around 20 overviews.
This number doesn’t only come from performance perspectives, but also from the view of an agent. Your agents will have their limits if you provide too many information at the same time. Sometimes less is more (in my opinion).
E.g.:
I don’t want to see my latest closed tickets. I know what I’ve done and if I’d have to take a look again, I’ll be using the search function. This saves ressources on the server side and removes irrelevant data I don’t need for 95% of my working time.
I don’t have to see all pending tickets - they’re pending for a reason => for me to not get distracted by those. If they’re pending reminders, they’ll pop up at a later moment (this is what an overview will want to show me so I can choose between open and pending reached tickets)
I don’t need overviews for dedicated groups, because if I end up having so many tickets that I need pagination (so like if I have 150 open tickets per group) I might have a whole other problem that I might need to solve.
at such a point I’d understand why you’d need or want to divide overviews by groups - this might also be a workflow issue. E.g. if you have a lot of open tickets, one could put those tickets in different ticket states “to get rid of them” as long as you don’t need them.
I think that’s pretty detailed for now.
Please have a look at overview configurations.
You can e.g. use “last updated within (relative) 14 days” as additional condition on such a ticket. This allows you to only show a specific time span of tickets.
Macros can’t help you here, unless those Macros do something to tickets so that your overview no longer meets the ticket conditions and thus the ticket vanishes from the affected overview.