Hey, thanks a lot for your answer!
You are right about trying to flatten the structure, yet the lowest level we could go is with a parent node and a child node. We could obviously implement that in Zammad too, using the tags as you already said or even with custom attributes.
However the big problem, which makes it troublesome for me to convince other colleagues, is the search function itself. It is really troublesome, mostly for older colleagues, to write search queries every time.
It doesn’t have to be a queue and subqueue really, but people are used to be able to klick on something that has the role of a parent structure, let’s say “first level support” and then to see the next hierarchy like maybe “accounts” in order to see all the open tickets in front of them that they have to work on. That is basically two klicks for them instead of writing ( tag: accounts
).
Personally I really love the functions of the search function and how Zammad is designed etc. but if you can only have like 20 Views before performance loss it loses a lot of user usability in my eyes. Also the fact that you can not structure views in like a tree structure makes it impossible to use it in a bigger IT-Department.
I can also understand that you guys want to keep a flat structure in Zammad. Maybe a solution could be that a user can save search queries and then trigger a search via klick? Let’s say you add a tab on the left side like “Knowledge Base”. When the user clicks on the menu, it drops down and shows saved search queries that the user can rename. It could be something like “Accounts” that triggers a “tag: accounts” and whatever the user initially searched with).
I hope that you guys understand where I am coming from and would really like to see a solution for this “problem” one day, given that you find enough development capacity.
Thank you very much for your work!